All XML attribute values and some element bodies are text strings. These strings are defined by data format. Each data format specifies the allowable form of the string, the corresponding XML Schema datatype, and the intended use of the value. The set of ODM data formats follows:
| Format Name | Schema Datatype | Allowed String Pattern |
| integer | xs:integer | -?digit+ |
| positiveInteger | xs:positiveInteger | +?digit+ (and representing an integer number > 0) |
| nonNegativeInteger | xs:nonNegativeInteger | +?digit+ (and representing an integer number >= 0) |
| decimal | xs:decimal | -?digit+(.digit+)? |
| float | xs:float | [\+\-]?\digit*\.?\digit+(?:[Ee][\+\-]?\digit+)? |
| double | xs:double | [\+\-]?\digit*\.?\digit+(?:[Ee][\+\-]?\digit+)? |
| date | xs:date | YYYY-MM-DD |
| time | xs:time | hh:mm:ss(.n+)? (((+|-)hh:mm)|Z)? |
| datetime | xs:dateTime | YYYY-MM-DDThh:mm:ss(.n+)?(((+|-)hh:mm)|Z)? |
| text | xs:string | any sequence of characters |
| value | xs:string | any sequence of characters |
| oid | xs:string | any sequence of characters (minLength="1") |
| oidref | xs:string | any sequence of characters (minLength="1") |
| ID | xs:ID | any sequence of characters (minLength="1") |
| IDREF | xs:IDREF | any sequence of characters (minLength="1") |
| subjectKey | xs:string | any sequence of characters (minLength="1") |
| repeatKey | xs:string | any sequence of characters (minLength="1") |
| name | xs:string | any sequence of characters (minLength="1") |
| fileName | xs:anyURI | any sequence of characters |
| languageTag | xs:language | LL (-CC)* (see below) |
| string | xs:string | Semantically equivalent to text but directly supported as XML Schema datatype |
| boolean | xs:boolean | (true | false | 1 | 0) |
| hexBinary | xs:hexBinary | hex-encoded binary stream data |
| base64Binary | xs:base64Binary | binary stream encoded using Base64 Alphabet |
| hexFloat | xs:hexBinary | up to 16 characters |
| base64Float | xs:base64Binary | up to 12 characters |
| partialDate | xs:date xs:gYearMonth xs:gYear | [YYYY[-MM[-DD ]]] |
| partialTime | xs:time xs:string | [hh[:mm[:ss(.n+)? (((+|-)hh:mm)|Z)?]]] |
| partialDatetime | xs:dateTime xs:string | [YYYY[-MM[-DD[T hh[:mm[:ss(.n+)? ((+|-)hh:mm)?]]]]]] |
| intervalDatetime | xs:string | partialDatetime/partialDatetime)|(durationDatetime/partialDatetime)|(partialDatetime/durationDatetime) |
| durationDatetime | xs:duration xs:string | (((+|-)?P((((n(n+)?)Y)?((nn+)?)M)?((nn+)?)D)?)(T(((n(n+)?)H)?((n(n+)?)M)?((n(n+)?)((\.n+)?)S)?)?)?|(((n(n+)?)W)))) |
| incompleteDatetime | xs:dateTime xs:string | [YYYY|-]-[MM |-]-[DD|-]]]T[hh|-]:[mm|-]:[ss.s|-][?(+|-)nn:nn|Z] |
| incompleteDate | xs:date xs:gYearMonth xs:gYear xs:string | [YYYY|-]-[MM |-]-[DD|-] |
| incompleteTime | xs:time xs:string | T[hh|-]:[mm|-]:[ss.s|-][?(+|-)nn:nn|Z] |
| URI | xs:anyURI |
Numbers are represented in base 10. Floats are allowed to have fractional parts.
Note: Certain integer attributes (i.e., KeySequence, OrderNumber, SequenceNumber, SeqNum) are used to define an order among related entities. For these attributes, we recommend using consecutive integer values starting at 1.
A text value is any character or sequence of characters valid within the XML document encoding. When embedded in ODM files, text strings must be represented using the standard XML quoting and character escaping rules.
Dates are represented in the Gregorian calendar. The year (YYYY) ranges from 0001 to 9999. The month (MM) ranges from 01 to 12. The day (DD) ranges from 01 to 31. ODM dates are equivalent to the XML Schema datatype date.
Times are clock readings within a 24-hour period. The hour (hh) ranges from 00 to 23. The minutes (mm) and the seconds (ss) range from 00 to 59. The optional fractional part (.nnn) expresses fractional seconds. The timezone can be either expressed using the ±hh:mm format or using the "Z" format (Coordinated Universal Time; UTC)
Datetimes combine a date, a time, and (optionally) a timezone.
Dates, times, and datetimes are to be interpreted as local clock readings at the place the data was collected. In a datetime, the ±hh:mm is the offset in hours and minutes to add to (or subtract from) UTC to get the local clock reading at the time the data was collected. A missing timezone specification means that the relationship between the local clock and UTC is not known.
Note: The above formats for dates, times, and datetimes are compatible with ISO 8601 (see "Complete Representations"). The ODM date, time, and datetime data formats must contain all element components.
Example: 3:14 pm on 3 January 2001 in Chicago (6 timezones west of Greenwich, standard time) would be represented as "2001-01-03T15:14:00-06:00". 3.5 seconds after midnight on the morning of July 20th 2001 in Chicago (daylight time) would be represented as "2001-07-20T00:00:03.500-05:00".
partialDate, partialTime and partialDatetime formats are compatible with ISO 8601(see "Representations other than complete"). They are provided to support transmission of dates in which 1 or more less significant components are unknown at the time of data capture. For example, for a partialDate value the day of the month may be unknown.
The intervalDatetime format is represented as a pair of partialDatetime values representing the beginning and end of the time interval, a beginning partialDatetime and a durationDatetime, or a durationDatetime and an ending partialDatetime separated by a slash (see "Representation of time-interval identified by its start and its end," "Representation of time-interval identified by its start and its duration," and "Representation of time-interval identified by its duration and its end," respectively).
The durationDatetime data format is represented as an ISO 8601 duration (see "Representation of time-interval by duration only") . For example, 4 hours and 35 minutes is represented as PT4H35M. In the ODM implementation, carryover of individual component values and negative durations are supported.
The incompleteDatetime format enables transmission of datetime values where 1 or more of the components—not necessarily of lower significance—is missing. The full set of delimiters is used as for a complete datetime; the missing component(s) are represented by a single dash (see "Truncated Representations"). In the ODM implementation, most meaningful partialDatetime forms are also supported. For example, 5 minutes after an unknown hour on the 15th day of an unknown month in 2004 is represented as 2004---15T-:05.
The incompleteDate format enables transmission of date values where 1 or more of the components—not necessarily of lower significance—is missing. The full set of delimiters is used as for a complete date; the missing component(s) are represented by a single dash (refer to "Truncated Representations"). For example, 2001---30 means the 30th of an unknown month in the year 2001, and ----30 means the 30th of an unknown month and unknown year.
The incompleteTime format enables transmission of time values where 1 or more of the components—not necessarily of lower significance— is missing. The full set of delimiters is used as for a complete time; the missing component(s) are represented by a single dash (refer to "Truncated Representations"). For example, -:55:30 means 30 seconds after the 55th minute of an unknown hour, and -:-:30 means 30 seconds after an unknown minute of an unknown hour.
The hexFloat and base64Float data formats are binary types intended for precise exchange of floating-point data in a machine/platform independent manner. The types are based on the IBM Mainframe format used in SAS V5 Transport format (described in the SAS Technical Support document "TS-140 The Record Layout of a Data set in SAS Transport (XPORT) Format") with the appropriate direct translation of the converted value to either hexBinary format or the base64Binary (MIME) representation. This secondary conversion ensures XML encoding compatibility.
Note: Data values transmitted as hexFloat or Base64Float will not be humanly readable in an XML markup or by a standard XML authoring tool. For this reason, the decision to use these types implies that an application will be needed to process data received in this format.
Values for hexFloat and hexBinary data are encoded as character tuples consisting of 2 hexadecimal digits ([0-9A-F]).
Values for base64Binary data are encoded using the 65 characters of the Base64Alphabet. These include a-z, A-Z, 0-9, +, /, = and the whitespace characters defined in [XML 1.0 (Fifth Edition)].
The hexBinary and base64Binary datatypes may also be used for exchange of floating point values, but may be subject to platform or application dependencies. Implementers should note that this could result in an inability to determine whether the receiving application has interpreted a value as a string rather than as a float. Encoded values using these datatypes may be exchanged reliably only across similar hardware platforms.
Note: ODM v1.1 allowed a timezone specification of -99:99 to designate "no timezone information." This format is no longer supported.
An oid (OID) is a string that uniquely identifies an element (see Section 2.13, Element Identifiers and References). An oidref is the use of an OID to reference an element (as opposed to the defining occurrence of that OID). OIDs and oidrefs are non-empty strings.
A subjectKey or repeatKey helps designate a clinical data entity (see Section 2.7, Clinical Data Keys). SubjectKeys are non-empty strings.
A name is intended to be a human readable name for some entity. Names are non-empty strings.
A fileName designates a file. File names are system dependent, and expressed relative to the directory that contains the ODM file being processed. FileNames are non-empty strings.
A languageTag represents a natural language or a country-specific variant of a natural language. The allowed values are specified in IETF RFC 3066: Tags for the Identification of Languages. Note that a languageTag cannot be null.
Example: "fr-CA" denotes the French language, Canadian variant. See Section 3.2.1.1, TranslatedText, for a discussion of how languageTags are used.
In general for data formats that allow NULLs, you should use an empty string (e.g., attribute-name="") to represent a NULL attribute value. To represent a NULL for data transmitted in an element body, send the element as empty (e.g. <element-name/>). There is a special IsNull indicator for clinical data, to differentiate between the case where there is no known value, and the case where you want to replace a value with NULL. See the IsNull attribute of the ItemData element (see Section 3.2.5.1.3, StudyEventData).
See the ODM Foundation Schema for definitions of the enumeration types.