Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Format NameSchema DatatypeAllowed String Pattern
integerxs:integer-?digit+
positiveIntegerxs:positiveInteger+?digit+ (and representing an integer number > 0)
nonNegativeIntegerxs:nonNegativeInteger+?digit+ (and representing an integer number >= 0)
decimalxs:decimal-?digit+(.digit+)?
floatxs:float[\+\-]?\digit*\.?\digit+(?:[Ee][\+\-]?\digit+)?
doublexs:double[\+\-]?\digit*\.?\digit+(?:[Ee][\+\-]?\digit+)?
datexs:dateYYYY-MM-DD
timexs:timehh:mm:ss(.n+)? (((+|-)hh:mm)|Z)?
datetimexs:dateTimeYYYY-MM-DDThh:mm:ss(.n+)?(((+|-)hh:mm)|Z)?
textxs:stringany sequence of characters
valuexs:stringany sequence of characters
oidxs:stringany sequence of characters (minLength="1")
oidrefxs:stringany sequence of characters (minLength="1")
IDxs:IDany sequence of characters (minLength="1")
IDREFxs:IDREFany sequence of characters (minLength="1")
subjectKeyxs:stringany sequence of characters (minLength="1")
repeatKeyxs:stringany sequence of characters (minLength="1")
namexs:stringany sequence of characters (minLength="1")
sasNamexs:string( letter | _ )( letter | digit | _ )* (maxLength="8")
sasFormatxs:string( letter | _ | $ )( letter | digit | _ | . )* (maxLength="8")
fileNamexs:anyURIany sequence of characters
languageTagxs:languageLL (-CC)* (see below)
stringxs:stringSemantically equivalent to text but directly supported as XML Schema datatype
booleanxs:boolean(true | false | 1 | 0)
hexBinaryxs:hexBinaryhex-encoded binary stream data
base64Binaryxs:base64Binarybinary stream encoded using Base64 Alphabet
hexFloatxs:hexBinaryup to 16 characters
base64Floatxs:base64Binaryup to 12 characters
partialDatexs:date xs:gYearMonth xs:gYear[YYYY[-MM[-DD ]]]
partialTimexs:time xs:string[hh[:mm[:ss(.n+)? (((+|-)hh:mm)|Z)?]]]
partialDatetimexs:dateTime xs:string[YYYY[-MM[-DD[T hh[:mm[:ss(.n+)? ((+|-)hh:mm)?]]]]]]
intervalDatetimexs:stringpartialDatetime/partialDatetime)|(durationDatetime/partialDatetime)|(partialDatetime/durationDatetime)
durationDatetimexs: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))))
incompleteDatetimexs:dateTime xs:string[YYYY|-]-[MM |-]-[DD|-]]]T[hh|-]:[mm|-]:[ss.s|-][?(+|-)nn:nn|Z]
incompleteDatexs:date xs:gYearMonth xs:gYear xs:string[YYYY|-]-[MM |-]-[DD|-]
incompleteTimexs:time xs:stringT[hh|-]:[mm|-]:[ss.s|-][?(+|-)nn:nn|Z]
URIxs:anyURI

...

serverId

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 1.1 allowed a timezone specification of -99:99 to designate "no timezone information." This format is no longer supported.

Info

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 ISO8601(refer to "Representations other than complete"). They are provided to support transmission of dates in which one 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 (refer to "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 (refer to "Representation of time-interval by duration only") . For example, 4 hours and 35 minutes is represented as PT4H35M. In the ODM implementation, carry-over of individual component values and negative durations are supported.

The incompleteDatetime format enables transmission of datetime values where one 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 (refer to "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 one 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 one 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"

Jira
serverIssue Tracker (JIRA)
serverId85506ce4-3cb3-3d91-85ee-f633aaaf4a45
keyODM2DEV-29
  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 two 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 (Fift Fifth Edition)].

Jira
serverIssue Tracker (JIRA)
85506ce4-3cb3-3d91-85ee-f633aaaf4a45
keyODM2DEV-30

...

name is intended to be a human readable name for some entity. Names are non-empty strings.sasName (or sasFormat) is any valid SAS Version 5 Transport Format name (or format). These are limited to 8 characters in length.

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.

...