oasis€¦ · web viewthe two digits in a mm format can have values from 1 to 12. d -- represents...

Universal Business Language (UBL) Date and Time RepresentationPosition Paper 5, 19 May 2023Document identifier:

p-stuhec-datetime-05.doc (Word)Location:

http://www.oasis-open.org/committees/ubl/ndrsc/drafts/Editors:

Gunther Stuhec, SAP AG <[email protected]>Mike Adcock, APACS <[email protected]>

Contributors:

Abstract:Abstract

Status:This is a draft document and is likely to change on a weekly basis.If you are on the [email protected] list for NDR subcommittee members, send comments there. If you are not on that list, subscribe to the [email protected] list and send comments there. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Security Services TC web page (http://www.oasis-open.org/committees/security/).

Copyright © 2001, 2002 The Organization for the Advancement of Structured Information Standards [OASIS]

document.doc 1 19 May 2023

1

2

3

4

56789

101112

1314151617181920212223242526

2728

1

2

http://www.oasis-open.org/committees/security/

mailto:[email protected]






http://www.oasis-open.org/committees/ubl/ndrsc/drafts/

http://www.oasis-open.org/committees/ubl/ndrsc/drafts/wd-ublndrsc-ndrdoc-12.doc

Table of Contents1 Summary................................................................................................................................ 42 Particular Point of Date and/or Time......................................................................................5

2.1 Option 1: CCT “DateTime.Type”.......................................................................................52.1.1 Advantages...........................................................................................................62.1.2 Disadvantages......................................................................................................6

2.2 Option 2: XSD-Built-In Datatypes.....................................................................................72.2.1 Advantages...........................................................................................................92.2.2 Disadvantages......................................................................................................9

2.3 Option 3: Additional Built-In Datatypes.............................................................................92.4 Thoughts........................................................................................................................ 122.5 Recommendation...........................................................................................................12

3 Duration................................................................................................................................ 143.1 Option 1: CCT “Value.Type”...........................................................................................15

3.1.1 Advantages.........................................................................................................153.1.2 Disadvantages....................................................................................................16

3.2 Option 2: CCT “Measure.Type”......................................................................................163.2.1 Advantages.........................................................................................................173.2.2 Disadvantages....................................................................................................17

3.3 Option 3: Built-In Datatype “xsd:duration”.......................................................................173.3.1 Advantages.........................................................................................................183.3.2 Disadvantages....................................................................................................18

3.4 Option 4: CCTs “DateTime.Type”...................................................................................183.4.1 Advantages.........................................................................................................193.4.2 Disadvantages....................................................................................................19

3.5 Thoughts........................................................................................................................ 203.6 Recommendation...........................................................................................................20

4 Period................................................................................................................................... 214.1 Option 1: CCTs “DateTime.Type”...................................................................................21


4.2 Option 2: ACC “PeriodDetails”.......................................................................................224.3 Option 2: ACC “PeriodDetails” with combined data types.............................................23



5 Periodicity/Recurrent............................................................................................................265.1 Periodicity / Recurrence.................................................................................................275.2 Option 1: CCTs “DateTime.Type”...................................................................................27



29

3031323334353637383940414243444546474849505152535455565758596061626364656667686970

3

4

5.3 Option 2: ACC: “RecurrenceDetails” with two Choices and one Frequency..................295.3.1 Advantages.........................................................................................................305.3.2 Disadvantages....................................................................................................30

5.4 Option 3: ACC: Improved “RecurrenceDetails”..............................................................315.4.1 Advantages.........................................................................................................325.4.2 Disadvantages....................................................................................................33


Appendix A. ISO 8601 Date and Time Formats............................................................................34A.1. ISO 8601 Conventions......................................................................................................34A.2. Truncated and Reduced Formats......................................................................................35A.3. Deviations from ISO 8601 Formats...................................................................................35

A.3.1. Sign Allowed..............................................................................................................35A.3.2. No Year Zero.............................................................................................................35A.3.3. More Than 9999 Years..............................................................................................35

Appendix B. Notices...................................................................................................................... 36


71727374757677787980818283848586

87

5

6

1 SummaryThere are different types, related to dates and/or time. This types have to include:

components that relate to a particular point in the progression of date and/or time components that relate to durations, i.e. measurements of time components that relate to periods between particular points components that relate the frequency in a defined period

Components can express data that is related to date and time in various degrees of precision, from years or even decades to fractions of a second. The current defined core component types and representation terms are not enough for the expression of all specific types. A number of representation terms as well as schema definition rules are needed to exchange or share information on dates and time. A duration has a different semantic meaning than data that identifies a point in the progress of time. The identification of a period, with a starting and an ending moment, is also semantically different. Information systems treat “dates” differently from “times”. A “year” is semantically completely different from a “second”. There four conclusions for the definition of representation terms as well as the schema:

…that the Controlled Vocabulary must lead people to focus on a single and unambiguous meaning for each word, to recommend a single standard word where there are many synonyms in use, and to register those as synonyms of the ‘preferred’ word. Even the Oxford English Dictionary does not clearly define many of the expressions in common use and gives alternative meanings, so we need to adopt just one of those meanings for the Controlled Vocabulary. … that we also need a Good Business Practice guide on how to think! This sounds dramatic, but it is quite relevant when one is thinking about ‘what is this piece of information?’, ‘how should I define it?’, ‘how is it used?’, ‘how can I think of it in a more generic and re-usable way?’ … that we need to make something fundamental and special to give us a good and flexible way of specifying ‘period’, or whatever we decide to call it … that we use for the format definition the ·primitive· datatypes as defined by XML Schema Part 2: Data Types only. The lexical formats of these datatypes are described by ISO 8601 (See Appendix A).


888990919293949596979899

100101102103104105106107108109110111112113114115116117

118

7

8

2 Particular Point of Date and/or TimeParticular point of date and/or time represents a specific instant date and/or time.

There are a high number of different possibilities for expressing the particular point of date and/or time. The current version of ebXML core component technical specification considers three different representation terms for the representation of any point of date and/or time. But there are further specific formats, which could be necessary for expressing points of date and/or time in a specific manner. These specific formats will be discussed in the following subchapters.

2.1 Option 1: CCT “DateTime.Type” The first option describes the using of the Core Component Type “DateTime.Type” according the ebXML CCTS V 1.8. The structure underneath shows the XML schema of the Core Component Type itself. The CCT exists of two types. The complexType “DateTimeType” is the CCT itself. It contains the attribute “formatText” and the value of the element based on the simpleType “DateTimeContent”. The attribute “formatText” represents the supplementary component “Date Time.Format.Text” and the simpleType “DateTimeContent” represents the content component “Date Time.Content”.

<xsd:simpleType name="DateTimeContent" id="000067"><xsd:restriction base="xsd:string">

<xsd:pattern value="\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}{2}[+-Z]\p{Nd}{2}:\p{Nd}{2}"/>

</xsd:restriction></xsd:simpleType><xsd:complexType name="DateTimeType" id="000066">

<xsd:simpleContent><xsd:extension base="cct:DateTimeContent">

<xsd:attribute name="formatText" type="token" use="optional" id="000068"/>

<xsd:attributeGroup ref="cct:commonAttributes"/></xsd:extension>

</xsd:simpleContent></xsd:complexType>

“formatText” can be used for the definition of the format itself. The convention of this definition should be based on ISO 8601. “DateTimeContent” includes the date and/or time value. Since the convention of ISO 8601 includes signs, letters and numbers, it is necessary to use the built-in datatype “xsd:string” for it. By the facet “pattern” for example it is possible to restrict the format convention itself.


Time

Point of Date and/or Time

TimeTime

Point of Date and/or Time

119120

122123124125126

127128129130131132133134

135

136137138139140141142143144145146147148149150

151152153154155156

9

10

All three Representation Terms “Date”, “DateTime” and “Time” can be derived from the Core Component Type “DateTime.Type” as described in ebXML CCTS V1.8. An instance from a Business Information Entity which is based on a specific representation term contains the content and may contains the attributes for the format as well as the common attributes. For example:

<IssueDateTime formatText="CCYY-MM-DDThh:mm:ss+hh:mm">2002-06-06T12:00:00+07:00

</IssueDateTime>

This example specifies precisely the time of 12.00.00 in UTC in a time zone that is offset by +7 hours from UTC, on the 6th of June 2002.

2.1.1 Advantages This definition considers exactly the definition of the ebXML CCTS V1.8 There are two possibilities for validation of date and time: The first one is the validation against the attribute “formatText”. This validation corresponds to ebXML CCTS V1.8. The second one is the validation against the facet “pattern”. This validation corresponds to the recommendation of XML Schema

2.1.2 Disadvantages This option is well enough for representation of the three representation terms: Date, Time and DateTime. But how is it possible to describe the other formats explained in chapter Error: Reference source not found and 2.4? There is no definition made yet in ebXML CCTS V1.8 This option does not use the primitive built-in datatypes from XML Schema for defining the different date and time formats. Therefore: The parser cannot use the standard way for validation of the date and time formats The validation against the attribute “formatText” is in a proprietary manner The validation against the facet “pattern” is too complex


Co re Com po nen t T yp e

Name = “DateTime.Type”

Representation Term

Name = “Date”

Representation Term

Name = “DateTime”

Representation Term

Name = “Time”

derived from

derived from

derived from

Co re Com po nen t T yp e

Name = “DateTime.Type”

Representation Term

Name = “Date”

Representation Term


Representation Term

Name = “Time”

derived from

derived from

derived from

157

159160161162163

164

165166167

168169170

171172173174175176177

178179180181182183184185186187188

11

12

2.2 Option 2: XSD-Built-In DatatypesThe current version of ebXML core component technical specification considers the following representation terms for definition of a point of date and/or time. And the second option views the using of the three different built-in datatypes for representing this three different date and time formats.

Name xsd: DataType

Definition Remarks

Time xsd:time The time within a (not specified) day.

A time includes according ISO 8601:hours, minutes, seconds,fraction seconds andoptional definition of the time zone in relation to the UTC time.

Date xsd:date A calender day within a particular calendar year.

A date includes, according ISO 8601:year, month andday

Date and Time

xsd:dateTime A particular point in the progression of time.

A date time includes according ISO 8601:year, month, day, hours, minutes, seconds, fraction seconds and time zone in relation to UTC time.

XML Schema:Like the following structure shows for each representation term “Date, Time and DateTime” there is one tuple of complexType for the representation term itself and a simpleType for its content component.

<xsd:simpleType name="DateContent" id="000067"><xsd:restriction base="xsd:string"/>

</xsd:simpleType><xsd:complexType name="DateType" id="000066">

<xsd:simpleContent><xsd:extension base="cct:DateContent">

<xsd:attributeGroup ref="cct:commonAttributes"/>


189190191192193

194

195196197198199

200

201202203204205206207

13

14

</xsd:extension></xsd:simpleContent>

</xsd:complexType><xsd:simpleType name="DateTimeContent" id="000067">

<xsd:restriction base="xsd:dateTime"/></xsd:simpleType><xsd:complexType name="DateTimeType" id="000066">



</xsd:simpleContent></xsd:complexType><xsd:simpleType name="TimeContent" id="000067">

<xsd:restriction base="xsd:time"/></xsd:simpleType><xsd:complexType name="TimeType" id="000066">

<xsd:simpleContent><xsd:extension base="cct:TimeContent">



The following graphic shows that every representation term is based on an equivalent built-in datatype. A basic core component type is not necessary any more.

An instance from a Business Information Entity which is based on one of these representation terms contains the content and may contains the common attributes:

<IssueDate uid="ID000003">1967-08-13

</IssueDate>


Representation Term

Name = “Date”

Representation Term


Representation Term

Name = “Time”

is based on

is based on

is based on

Built-In Datatype

Name = “xsd:Date”

Built-In Datatype

Name = “xsd:DateTime”

Built-In Datatype

Name = “xsd:Time”

Representation Term

Name = “Date”

Representation Term


Representation Term

Name = “Time”

is based on

is based on

is based on

Built-In Datatype

Name = “xsd:Date”

Built-In Datatype

Name = “xsd:DateTime”

Built-In Datatype

Name = “xsd:Time”

208209210211212213214215216217218219220221222223224225226227228229230

231232233

234

236237

238

239240241

242

15

16

2.2.1 Advantages The structure is based completely on the XML Schema Definition, it can be used by every parser. An additional attribute or a facet is not necessary for validation reasons. There can be represented some more specific types of dates

2.2.2 Disadvantages The structure does not fit to the ebXML CCTS V1.8 There are some more representation terms necessary It can not define the formats as described in chapter 2.4

2.3 Option 3: Additional Built-In DatatypesThe XML Schema Part 2: Datatypes considers further datatypes for describing specific formats of a specific point of date and/or time. The following table shows these primitive built-in datatypes. We can use this primitive built-in datatypes for representing the further possibilities for representing a point of date and/or time.

Name xsd: DataType Definition Remarks

Year xsd:gYear A particular calendar year

A Year includes according ISO 8601:year

YearMonth xsd:gYearMonth A specific month in a specific year.

A YearMonth includes according ISO 8601: year and month

Month xsd:gMonth A specific month, that can recurs every year

A Month includes according ISO 8601: month

MonthDay xsd:gMonthDay The ordinal number of a day within a defined month.

A month includes according ISO 8601:year andday Recurring, to designate e.g. the 5th day of each month. Mind that months can have 28, 29, 30 or 31 days. A day starts at the hour 0000 and ends at 2400, which is equal to the beginning of 0000 the next day

Day xsd:gDay The day that recurs within a month.

A month includes according ISO 8601:day


243244245246247248

249250251252

253

254255256257258

259

260

17

18

This option is an addition to chapter 2.2 and can be used for all other defined built-in datatypes for representing different date and time formats. Therefore a representation term should be defined for every built-in datatype, like:

XML Schema:

<simpleType name="YearContent" id="000067"><restriction base="xsd:gYear"/>

</simpleType><complexType name="YearType" id="000066">

<simpleContent><extension base="cct:YearContent">

<attributeGroup ref="cct:commonAttributes"/></extension>

</simpleContent></complexType><simpleType name="YearMonthContent" id="000067">

<restriction base="xsd:gYearMonth"/></simpleType><complexType name="YearMonthType" id="000066">

<simpleContent><extension base="cct:YearMonthContent">


</simpleContent></complexType><simpleType name="MonthContent" id="000067">


Representation Term

Name = “Year”

Representation Term

Name = “YearMonth”

Representation Term

Name = “Month”

is based on

is based on

is based on

Built-In Datatype

Name = “xsd:gYear”

Built-In Datatype

Name = “xsd:gYearMonth”

Built-In Datatype

Name = “xsd:gMonth”

Representation Term

Name = “MonthDay”

Representation Term

Name = “Day”

is based on

is based on

Built-In Datatype

Name = “xsd:gMonthDay”

Built-In Datatype

Name = “xsd:gDay”

Representation Term

Name = “Year”

Representation Term


Representation Term

Name = “Month”

is based on

is based on

is based on

Built-In Datatype


Built-In Datatype


Built-In Datatype


Representation Term

Name = “Year”

Representation Term


Representation Term

Name = “Month”

is based on

is based on

is based on

Built-In Datatype


Built-In Datatype


Built-In Datatype


Representation Term

Name = “MonthDay”

Representation Term

Name = “Day”

is based on

is based on

Built-In Datatype

Name = “xsd:gMonthDay”

Built-In Datatype

Name = “xsd:gDay”

261262263

264

266

267

268269270271272273274275276277278279280281282283284285286287288

19

20

<restriction base="xsd:gMonth"/></simpleType><complexType name="MonthType" id="000066">

<simpleContent><extension base="cct:MonthContent">


</simpleContent></complexType><simpleType name="MonthDayContent" id="000067">

<restriction base="xsd:gMonthDay"/></simpleType><complexType name="MonthDayType" id="000066">

<simpleContent><extension base="cct:MonthDayContent">


</simpleContent></complexType><simpleType name="DayContent" id="000067">

<restriction base="xsd:gDay"/></simpleType><complexType name="DayType" id="000066">

<simpleContent><extension base="cct:DayContent">


</simpleContent></complexType>

XML Instances:

<IssueYear uid="ID000014">2001</IssueYear>

This example states that the issue year will be 2001.

<IssueYearMonth uid="ID000015">2001-12</IssueYearMonth>

This example states that the issue month will be December in 2001.

<IssueMonth uid="ID000016">--12--</IssueMonth>

This example states that the issue month will be December.


289290291292293294295296297298299300301302303304305306307308309310311312313314315316317

318319

320

321

322323

324

325

326327

328

329

330331

332

21

22

<IssueMonthDay uid="ID000017">--12-17</IssueMonthDay>

This example states that the issue day will be the 17th in December.

<IssueDay uid="ID000018">---17</IssueDay>

This example states that the issue day will be the 17th.

2.4 ThoughtsDifferent standards, like ISO 8601, UN/EDIFACT, ANSI ASC X.12, UN/CEFACT Recommendation 20 and some XML dialects considers further possibilities for representing a point of date and/or time in a specific manner which could not represented by the definitions above. This additional representation formats could be possible in a specific business semantic.

Name Definition Remarks

Ordinal week within a year

The ordinal number of a week within a specific year

includes according to ISO 8601:year andweek

Ordinal day within a Year

The ordinal number of a day within a specific year

includes according to ISO 8601:year andday

Day within a Week

The day of a week, expressed in a name or in an ordinal number

includes according to ISO 8601:week andday Monday has the ordinal number 1, Tuesday 2, etc to Sunday 7. This can be recurrent, to express e.g. each Tuesday.

Quarter Three months period of a specific year.

Trimester Four months period of a specific year

Semester Six months period of a specific year.

2.5 RecommendationIt is possible to define all business dependent date and/or time definitions for expressing any particular points by the three representation terms “Date, Time and DateTime”. All another specific date time formats could be either calculated into one of the three representation terms or can be expressed by the additional built-in datatypes: gYear, gYearMonth, gMonth, gMonthDay,


333

334335

336

337

338339

340

341342343344345

346

347

348349350351352

23

24

gDay. And if it not so, it is possible to express this information by using “duration” like: Quarter, Trimester, Semester.


353354

25

26

3 DurationDuration represents the measure (“length”) of a date and/or time. Duration consists of a combination of the atoms years, months, days, hours, minutes and seconds. Duration can also be expressed in other units, like weeks or working days, or duration can entirely be expressed in seconds, even if it spans a year.

For components that relate to duration:

name definition remarks

seconds A second is the basic unit of measurement of time as defined in ISO 31-1

Seconds may be expressed as a real number, with a maximum precision that is dependent on the way of representation

minutes One minute is a duration of 60 seconds

Minutes are expressed as whole numbers. Fractions of minutes are expressed in seconds.

hours One hour is a duration of 60 minutes

Hours are expressed in whole numbers. Fractions of hours are expressed in minutes and seconds

days One day is a duration of 24 hours

Fractions of days are expressed in hours, minutes and seconds

weeks One week is a duration of 7 days

months A month is a duration resulting from the division of a calendar year in twelve sequential periods, each with a specific name and containing a specified number of days

In the Gregorian calendar, the months of the calendar year, listed in their order of occurrence, are named and contain the number of days as follows:01 – January: 3102 – February: 28 in normal years, 29 in leap years03 – March: 3104 – April: 3005 – May: 3106 – June: 3007 – July: 3108 – August: 31


Time

Duration of Date and/or Time

Time

Duration of Date and/or Time

355356357358359

360

362363

364

27

28

09 – September: 3010 – October: 3111 – November: 3012 – December: 31If unspecified, the number of days in a (average) month is 30.44 days or 30 days 10 hours 29 minutes and 1 second.

years One year is a duration of 365 days (common years) or 366 (leap years)

If unspecified, the length of a (average) year is 365.2425 days, or 365 days, 5 hours, 49 minutes and 12 seconds.

There are four options for representing duration.

3.1 Option 1: CCT “Value.Type”The duration is a real number of date and/or time, which is assigned or is determined by calculation, counting or sequencing. This number is a numeric value and can be represented by the representation term “Value” which is based on the core component type “Numeric.Type”.

<simpleType name="NumericContent" id="000153"><restriction base="decimal"/>

</simpleType><complexType name="NumericType" id="000204">

<simpleContent><extension base="cct:NumericContent">

<attribute name="formatText" type="string" use="optional" id="000204"/>



The definition of a local BBIE will be:

<element name="PaymentDaysValue" type="cct:NumericType"/>

And an instance of the BBIE could be:

<PaymentDaysValue uid="ID000005">3.21</PaymentDaysValue>

This example states that the number of days before payment is due is 3.21.


365366

367368369370

371

372373374375376377378379380381382383

384385

386

387

388389

390

391

392393

29

30

3.1.1 Advantages The dictionary entry names representing the names of a BBIE with a correct business meaning This solution will be used in the LCSC yet Easy to use

3.1.2 Disadvantages The kind of date and/or time format must be always defined as a part of the property terms, because there is no possibility to express that format in another way. It is difficult to distinguish between formats and units of time measurement by a parser or an API. The API or parser has to analyse the BBIE for that. It is difficult to use any kind of value for further calculation together with any another data and/or time formats.

3.2 Option 2: CCT “Measure.Type”Duration is a measure (“length”) of date and/or time. The measure can be expressed by the core component type “Measure.Type”. The supplementary component represents the unit of measure as a code for any unit of time. Units listed in ECE rec. 20 are:

Unit Code

Second SEC

Minute MIN

Hour HUR

Day DAY

Week WEE

Ten days DAD

Month MON

Quarter (of a year) QAN

Half year (six months) SAN

Year ANN

Decade (ten years) DEC

The schema definition of a “Measure.Type” is then:

<simpleType name="MeasureContent" id="000153"><restriction base="decimal"/>

</simpleType>


394395396397398

399

400401402403404405406

407

408409410411

412

413414

415

416417418

31

32

<complexType name="MeasureType" id="000152"><simpleContent>

<extension base="decimal"><attribute name="unitCode" type="string" use="required"

id="000154"/><attributeGroup ref="cct:commonAttributes"/>

</extension></simpleContent>

</complexType>

The definition of a BBIE could be:

<element name="PaymentDaysMeasure" type="cct:MeasureType"/>

And the instance is:

<PaymentDaysMeasure unitCode="DAY">3</PaymentDaysMeasure>

This example states that the payment is due in 3 days.

3.2.1 Advantages The dictionary entry names representing the names of a BBIE with a correct business meaning The kind of date and/or time will be represented by the unit of measure attribute The kind of date and/or time must not always be defined as a property term The value can be used for further calculation with another date and/or time values in an easier way.

3.2.2 Disadvantages The value is not expressed in an XML Schema defined date and/or time format A combination of the different date and time atoms is not possible, if this not expressed by any code of the Rec. 20 itself. For example the combination of month and year in saying "two months and ten days time".

3.3 Option 3: Built-In Datatype “xsd:duration”Time durations are periods expressed in terms of years, months, days, hours, minutes and/or seconds. These values can be expressed in the specific ISO 8601 format for duration. These are expressed as an integer (or decimal number) followed by a letter. The letter P is used to identify the start of the period definition, the letter T being used to identify the start of the time components within the period. The basic format of a duration definition is PnYnMnDTnHnMnS,


419420421422423424425426427

428429

430

431

432433

434

435

436437

438

439440441442443444445

446

447448449450451

452

453454455

456457458

33

34

where n is the appropriate integer/decimal. Values can be truncated by omitting one or more of the lower order numbers and the associated qualifying letter. The whole of the date can also be omitted by following the P with a T.

This specific ISO 8601 format will be expressed by the built-in datatype “xsd:duration”. For that option is an additional representation term “Duration” necessary. This representation will be used for defining the schema:

<simpleType name="DurationContent" id="000300"><restriction base="duration">

<pattern value='P\p{Nd}{4}Y\p{Nd}{2}M\p{Nd}{2}D'/></restriction>

</simpleType><complexType name="DurationType" id="000299">

<simpleContent><extension base="decimal">



A further restriction by the facet “pattern” is possible.The instance for a duration could be:

<PaymentDaysDuration>P1Y2M3DT10H30M</PaymentDaysDuration>

This (unlikely) example states that the duration for payment is 1 year, 2 months, 3 days, 10 hours and 30 minutes.

3.3.1 Advantages XML schema compliant Calculable with another XML schema based date and time formats A complex expression of special date and time formats is possible The representation term “duration” express a correct business meaning Restrictable by using the facet “pattern”

3.3.2 Disadvantages Not ebXML CCTS V1.8 compliant Additional representation term is necessary The ISO 8601 convention is not easy to understand

3.4 Option 4: CCTs “DateTime.Type”According to the ebXML CCTS V1.8 the ISO 8601 based format for duration could be expressed by the supplementary component “DateTime.Format.Text” of the core component type


459460

461462463464465

466

467468469470471472473474475476477478

479480481

482

483

484485486

487488489490491492

493494495496

497498499

35

36

“DateTime.Type”. This supplementary component will be defined as an attribute “formatText”. The format definition itself will be defined by the ISO 8601 conventions for duration of a period of time. This convention will be always preceded by the designator [P]. The duration will be expressed by a number of years [Y], months [M], weeks [W], days [D] and the number of time with the preceded [T]. The time is divided in number of hours [H], minutes [M] and seconds [S].The basic format of duration of time is:

PnYnMnDTnHnMnS

For example:

P2Y5M12DT10H23M20S

See following example shows the schema specification of duration by using DateTime.Type. Please note that the definition of format can be done in two ways. The first way is the definition by using the attribute “formatText” and the second way is the restriction by using the facet “pattern” within the simpleType “DateTimeContent”:

<simpleType name="DateTimeContent_1" id="000067"><restriction base="xsd:string">

<pattern value='P\p{Nd}{0,4}Y\p{Nd}{0,2}M\p{Nd}{0,2}D'/></restriction>

</simpleType><complexType name="DateTimeType_1" id="000066">

<simpleContent><extension base="cct:DateTimeContent_1">

<attribute name="formatText" type="token" use="optional" id="000068"/>



As described in chapter 2.1, it is possible to restrict the format for the content component by using the facet “pattern”. Therefore, there are two possibilities to validate the format itself.<PaymentDaysDate formatText="PnYnMnD">P2Y6M6D</PaymentDaysDate>This example states that the Payment Date is in 2 years, 6 months and 6 days.

3.4.1 Advantages Two possibilities of validation ebXML CCTS V1.8 compliant

3.4.2 Disadvantages No standard XML schema validation of duration The convention of the format must be always expressed by an attribute or facet. The ISO 8601 convention for duration itself is not easy to understand


500501502503504505

506507

508509

510511

512513514515516

517

518519520521522523524525526527528529530531

532533534535536

537538539

540541542543

37

38

The duration is a measure of time and could not be expressed by the representation terms “Date”, “DateTime” and “Time”. This is a complete different business meaning. (It is necessary to create an additional representation term like “Duration”.)

3.5 ThoughtsIn some cases, there is a need for either an event code and/or an event indicator to be associated with the duration. This event code and event indicator sets either the starting or the ending point in a special kind of business situation, where the situation is not yet a known point in time. Such a situation could be the need to express, for example, that payment is due 30 days after the receipt of an invoice in setting up contract details before even the order is placed.

3.6 RecommendationFor any expression of a duration the ISO 8601 convention will be very helpful.


544545546547

548

549550551552553554

555

556557

39

40

4 PeriodPeriod represents the time frame from a defined beginning time and/or date to a defined ending time and/or date.

The period itself can expressed in three different varieties. They can be specified by any of: start and end time and/or date start and a duration duration and an end

4.1 Option 1: CCTs “DateTime.Type”

<simpleType name="DateTimeContent" id="000067"><restriction base="xsd:string">

<pattern value="\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}

{2}[/]\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}

{2}"/> </restriction>

</simpleType><complexType name="DateTimeType" id="000066">

<simpleContent><extension base="cct:DateTimeContent">

<attribute name="formatText" type="token" use="optional" id="000068"/>



Example of an instance:

<ValidityPeriodDateTime formatText="CCYY-MM-DDThh:mm:ss\CCYY-MM-DDThh:mm:ss ">


Time

Beginning Date and/or Time

Ending Date and/or Time

Time



558559560

561

563564565566567

568

569

570

571572573574575576577578579580581582583584585586587588

589590

591

592593

41

42

2002-01-01T00:00:00/2002-06-06T12:00:00</ValidityPeriodDateTime>

This example is stating that the validity period is from the beginning of 1st Jan 2002 until mid-day on 6th June 2002.

4.1.1 Advantages ebXML CCTS V1.8 compliant Every possibility could be expressed by using the ISO 8601 conventions

4.1.2 Disadvantages Not XML Schema compliant The convention of the format must be always expressed by an attribute or facet. The ISO 8601 convention is not easy to understand and interpret Too complex for the business requirements Not easy to use by APIs or parsers

4.2 Option 2: ACC “PeriodDetails” The period consists of a start point and an end point. These points could be expressed by one of the three representation types: “Date, Time and DateTime”. For the definition of this kind of period, an Aggregate Core Component could be useful. This ACC could be named as “PeriodDetails” and contains two subgroups of choices. The first choice includes all representation types for the starting point and the second includes all representation types for the ending point. Since both points in time must exist, one choice for each has to be mandatory.Diagram:

XML-Schema:

<complexType name="PeriodDetails"><sequence>

<choice><element name="StartTime" type="cct:TimeType"/><element name="StartDate" type="cct:DateType"/>


594595

596597598

599600601

602

603604605606607608

609

610611612613614615616617

618619620

621

622623624625626

43

44

<element name="StartDateTime" type="cct:DateTimeType"/></choice><choice>

<element name="EndTime" type="cct:TimeType"/><element name="EndDate" type="cct:DateType"/><element name="EndDateTime" type="cct:DateTimeType"/>

</choice></sequence>

</complexType>

XML-Instance:

<ValidityPeriod><StartDate>1967-08-13</StartDate><EndDate>1967-08-13</EndDate>

</ValidityPeriod>

This example is stating that the validity period is from the 13th Aug 1967 to 13th August 1967, i.e. that day.

4.3 Option 2: ACC “PeriodDetails” with combined data typesThe period exists of a start point and an end point. These points can be expressed by one of the three representation types: “Date, Time and DateTime”. The three different possibilities can be selected by a “choice”.

Diagram:

XML-Schema:

<complexType name="PeriodDetails"><choice>

<sequence minOccurs="0"><element name="StartTime" type="cct:TimeType"/>


627628629630631632633634635

636637

638

639640641642

643644645

646647648649

650651

652653

654655656

657

658659660661

45

46

<element name="EndTime" type="cct:TimeType"/></sequence><sequence minOccurs="0">

<element name="StartDate" type="cct:DateType"/><element name="EndDate" type="cct:DateType"/>

</sequence><sequence minOccurs="0">

<element name="StartDateTime" type="cct:DateTimeType"/><element name="EndDateTime" type="cct:DateTimeType"/>

</sequence></choice>

</complexType>

XML-Instance:

<ValidityPeriod><StartDate>1967-08-13</StartDate><EndDate>1967-08-13</EndDate>

</ValidityPeriod>

This example is stating that the validity period is from the 13th Aug 1967 to 13th August 1967, i.e. that day.

4.3.1 Advantages XML schema compliant Calculable with another XML schema based date and time formats A complex expression of special date and time formats is possible The representation term “period” expresses a correct business meaning Restrictable by using the facet “pattern” Well enough for the requirements to express all business meanings Reduced but correct selection of the data types for representing starting and ending points

4.3.2 Disadvantages Not ebXML CCTS V1.8 compliant For every representation term is a child-element necessary

4.4 ThoughtsAn event code and/or an event indicator is necessary for some business circumstances. This event code and event indicator sets the starting and ending point in a special kind of business


662663664665666667668669670671672673

674675

676

677678679680

681682683

684

685686687688689690691692693

694

695696697

698

699700701

47

48

situation, if this situation is not a precise point of time. A situation could be the receiving of a document, such as an invoice.The event code itself expresses the business situation, like “invoice, holiday etc.” and the event indicator defines that the specific period will be happen before (0) or after (1) this situation.

4.5 RecommendationThe expression of a period by the two points in date/times: start and end date/times are sufficient. If the start or the end date/time known, it is possible to calculate the other point of date/time by duration and start or end date/time respectively.


702703704705

706707708709

710711

49

50

5 Periodicity/RecurrentPeriodicity represents recurring times and/or dates within a period (start and end date/time) or a duration (measure of time).

A periodicity can be expressed in one of the following ways:

By a number of recurrences at points over a defined period of time. In this the period is identified by the first two components of the expression, and the frequency is expressed by the last component. If the last component is absent the number of occurrences is unbounded. The frequency may either be a number of occurrences, or specific occurrences such as 'every nth day of the month', during the period.

By recurrences at time intervals over a period, with the indicated duration for each time-interval between recurrences. In this the period is identified by the first two components of the expression, and the interval between recurrences by the last component.By a number of recurrences over a duration. In this the duration is identified by the first component of the expression, and the frequency is expressed by the last component. The frequency may either be a number of occurrences, or specific occurrences such as 'every nth day of the week', during the duration.

By recurrences at time intervals over a duration, with the indicated duration for each time-interval between recurrences. In this the duration is identified by the first component of the expression, and the interval between recurrences by the last component.

5.1 Periodicity / RecurrenceThe periodicity represents the recurring of dates and/or times within a period or a duration. As described in chapter 2.4 is this possible in four different ways:

Frequency within a period, intervals within a period, frequency within a duration and intervals withing a duration,

For these four possibilities the following parameters are necessary: Beginning date/time and ending date/time for a period


Time



FrequencyFrequencyFrequency

Time



Intervals

Time



FrequencyFrequencyFrequency

Time



Intervals

712713714

715716

717718719720721722723

725726727728729730731

732733734735

736

737738739740741742743744745

51

52

Duration Expression of an interval Expression of a frequency

There are three options for representing periodicity / recurrence. Not all of these options could represent all four different possibilities. The restricitions will be described in each chapter of the options.

5.2 Option 1: CCTs “DateTime.Type”According to the ebXML CCTS V1.8 the ISO 8601 based format for recurring time-intervals could be expressed by the supplementary component “DateTime.Format.Text” of the core component type “DateTime.Type”. The supplementary component will be defined as an attribute “formatText”. The format definition itself will be defined by the ISO 8601 conventions but all representations start with the designator [R], followed, without spaces, by the number of recurrences.The basic format of recurring time-intervals is:

Rn/YYYY-MM-DDThh:mm:ss/YYYY-MM-DDThh:mm:ssRn/YYYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnSRn/PnYnMnDTnHnMnS/YYYY-MM-DDThh:mm:ss

For example:

R12/l985-04-12T23:20:50/1985-06-25T10:30:00R12/1985-04-12T23:20:50/P1Y2M15DT12H30M0SR12/P1Y2M15DT12H30M0S/1985-04-12T23:20:50

This option could represent the number of frequency for period and duration by using the defining the number of recurrences. But a representation of interval is not possible.The following XML-Schema defines the core component type “DateTime.Type”. Please note that the definition of recurring time-intervals could be done in two possible ways. The first possibility is the expression of the format by the attribute “formatText” and the second on is the restriction of the format by using the facet “pattern” inside of the simpleType “DateTimeContent”:

<xsd:simpleType name="DateTimeContent" id="000067"><xsd:restriction base="xsd:string">

<xsd:pattern value="R\p{Nd}{1}[/]\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\

p{Nd}{2}:\p{Nd}{2}[/]\p{Nd}{4}-\p{Nd}{2}-\p{Nd}{2}T\p{Nd}{2}:\p{Nd}{2}:\p{Nd}

{2}"/></xsd:restriction>

</xsd:simpleType><xsd:complexType name="DateTimeType" id="000066">


<xsd:attribute name="formatText" type="token" use="optional" id="000068"/>


746747748

749750751752

753754755756757758759760

761762763764

765766

767768769770

771772773774775776777

778

779780781782783784785786787788789790791792

53

54



XML-Instance:

<BookingRecurrenceDateTime formatText="Rn/CCYY-MM-DDThh:mm:ss/CCYY-MM-DDThh:mm:ss">R0/0000-00-00T00:00:00/0000-00-00T00:00:00

</BookingRecurrenceDateTime>

This example suggests that nothing recurs at the precise beginning of time!!!! It may be true but not very illustrative.

5.2.1 Advantages ebXML CCTS V1.8 compliant Every possibility could be expressed by using the ISO 8601 conventions

5.2.2 Disadvantages Not XML Schema compliant The convention of the format must be always expressed by an attribute or facet. The ISO 8601 convention is not easy to understand and interpret Too complex for the business requirements Not easy to use by APIs or parsers No representation of an interval

5.3 Option 2: ACC: “RecurrenceDetails” with two Choices and one Frequency

The recurrence exists of a starting point, an ending point and the frequency itself. For defining a recurrence it is not always necessary to use the starting and ending point. In some business cases, a recurrence can exists of a starting point or an ending point only. Sometimes, it will be well enough, to define the frequency only. To define all this situations, the starting and ending points are optional and the frequency itself is mandatory.The starting and ending point are like the “PositionDetails” a choice of one of the three representation terms.The frequency itself based on a built-in data type “token”. By that, it is possible to express all ISO 8601 specific representation formats for the representing the frequency itself. Note: The built-in datatype “xsd:duration” could not express the recurrence conventions from ISO 8601. Therefore it is not possible to use “xsd:duration” for frequency.Diagram:


793794795796

797798

799

800801802803

804805806

807808809

810

811812813814815816817

818

819820821822823824825826827828829830831832

55

56

XML Schema:

<xsd:simpleType name="FrequencyContent"><xsd:restriction base="xsd:token">

<xsd:pattern value="R[/]P\p{Nd}{1}Y\p{Nd}{1}M\p{Nd}{1}DT\p{Nd}{1}H"/>

</xsd:restriction></xsd:simpleType><xsd:complexType name="FrequencyType">

<xsd:simpleContent><xsd:extension base="cct:DurationContent">


</xsd:simpleContent></xsd:complexType><xsd:complexType name="RecurrenceDetails">

<xsd:sequence><xsd:choice minOccurs="0">

<xsd:element name="StartTime" type="cct:TimeType"/><xsd:element name="StartDate" type="cct:DateType"/><xsd:element name="StartDateTime" type="cct:DateTimeType"/>

</xsd:choice><xsd:element name="Frequency" type="cct:FrequencyType"/><xsd:choice minOccurs="0">

<xsd:element name="EndTime" type="cct:TimeType"/><xsd:element name="EndDate" type="cct:DateType"/><xsd:element name="EndDateTime" type="cct:DateTimeType"/>

</xsd:choice></xsd:sequence>

</xsd:complexType>

Instance:

<BookingRecurrence><StartDate>1967-08-13</StartDate><Frequency>R/P1M</Frequency>


833834835

836

837838839840841842843844845846847848849850851852853854855856857858859860861862863864

865866

867

868869870

57

58

<EndDate>1977-08-13</EndDate></BookingRecurrence>

This example states recurrence at monthly intervals between the dates 13th August 1967 and 13th August 1977.

5.3.1 Advantages XML schema compliant Calculable with another XML schema based date and time formats A complex expression of special date and time formats is possible The representation term “period” expresses a correct business meaning Restrictable by using the facet “pattern” Well enough for the requirements to express all business meanings

5.3.2 Disadvantages Not ebXML CCTS V1.8 compliant The ISO 8601 convention is not easy to understand By using the ISO 8601 standard it is possible to express nearly every kind of frequency. But there are some expressions of frequency, which could not defined by the ISO 8601 conventions. Like: Every <n> day in a month Every <n> day in a week Every working day in a week Every weekend day in a week

5.4 Option 3: ACC: Improved “RecurrenceDetails”The following recurrence is an improved representation of option 2. Each tuple of starting and ending point are now categorically summerised by a sequence. The different tuples are combined by a choice. With that structure it is only possible, a start and/or a ending point of special type of date and/or to be represented. The element “RecurrenceDetails” includes the number of recurrences. This number will be represented as an integer value. Note: ISO 8601 using the designator “R” for representing the number of recurrences. The data type “xsd:duration” does not permit however in the representation this designator. Therefore it is more favourable that this value is represented outside of “duration”. The next choice gives the possibility to represent the different type of frequency. These different frequency types allows the representation of nearly all possibilities like:

Every <n> day in a month Every <n> day in a week Every working day in a week Every weekend day in a week


871872

873874875

876877878879880881882

883

884885886887888889890891892893

894

895896897898899900901902903904905906907908909910

911

59

60

Diagram:

XML Schema:

<complexType name="RecurrenceDetails"><sequence>

<choice><sequence minOccurs="0">

<element name="StartTime" type="cct:TimeType" minOccurs="0"/>

<element name="EndTime" type="cct:TimeType" minOccurs="0"/>


<element name="StartDate" type="cct:DateType" minOccurs="0"/>

<element name="EndDate" type="cct:DateType" minOccurs="0"/>


<element name="StartDateTime" type="cct:DateTimeType"minOccurs="0"/>

<element name="EndDateTime" type="cct:DateTimeType"minOccurs="0"/>

</sequence></choice>


912913

914

915916917

918

919920921922923924925926927928929930931932933934935936937938939940

61

62

<element name="RecurrenceValue" type="cct:ValueType" minOccurs="0"/>

<choice><element name="FrequencyDuration" type="cct:DurationType"/><element name="FrequencyYear" type="xsd:gYear"/><element name="FrequencyYearMonth" type="xsd:gYearMonth"/><element name="FrequencyMonth" type="xsd:gMonth"/><element name="FrequencyMonthDay" type="xsd:gMonthDay"/><element name="FrequencyDay" type="xsd:gDay"/>

</choice></sequence>

</complexType>

Instance:

<BookingRecurrence><StartDate>1997-08-13</StartDate><EndDate>2001-12-13</EndDate><RecurrenceValue>33</RecurrenceValue><FrequencyDuration>P1Y2M3DT10H30M</FrequencyDuration>

</BookingRecurrence>

This example appears to state 33 recurrences between the dates of 13th August 1997 and 13th December 2001 where the duration of each recurrence is 1 year, 2 months, 3 days, 10 hours and 30 minutes.

5.4.1 Advantages XML schema compliant Calculable with another XML schema based date and time formats A complex expression of special date and time formats is possible The representation term “period” expresses a correct business meaning Restrictable by using the facet “pattern” Well enough for the requirements to express all business meanings Representation of near all different possibilities of frequency Represents all four possibilities.

5.4.2 Disadvantages Not ebXML CCTS V1.8 compliant Very complex

5.5 ThoughtsIn scenarios where the periodicity is within a duration, there may in some cases be a need for either an event code and/or an event indicator to be associated with the duration. This event code


941942943944945946947948949950951952

953954

955

956957958959960961

962963964965

966967968969970971972973974

975

976977978

979980981

63

64

and event indicator sets either the starting or the ending point in a special kind of business situation, where the situation is not yet a known point in time. Such a situation could be the need to express, for example, in a request for quotation that a delivery is required every 5 days over a period of 6 months from placement of an order.Is it necessary that all leaf elements are based on CCTs, even if they belong to a group like recurrence?

5.6 RecommendationThe expression of a period by the two point of times: start and end times are sufficient. If the start or the end time known, it is possible to calculate the another point of time by duration and start or end time respectively.All four scenarios illustrated above are necessary.


982983984985986987

988

989990991992993

994

65

66

Appendix A. ISO 8601 Date and Time Formats

A.1. ISO 8601 ConventionsThe ·primitive· datatypes duration, dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth and gYear use lexical formats inspired by [ISO 8601]. This appendix provides more detail on the ISO formats and discusses some deviations from them for the datatypes defined in this specification. [ISO 8601] "specifies the representation of dates in the proleptic1 Gregorian calendar and times and representations of periods of time". The proleptic Gregorian calendar includes dates prior to 1582 (the year it came into use as an ecclesiastical calendar). It should be pointed out that the datatypes described in this specification do not cover all the types of data covered by [ISO 8601], nor do they support all the lexical representations for those types of data. [ISO 8601] lexical formats are described using "pictures" in which characters are used in place of digits. For the primitive datatypes dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth and gYear. these characters have the following meanings:

C -- represents a digit used in the thousands and hundreds components, the "century" component, of the time element "year".Legal values are from 0 to 9. Y -- represents a digit used in the tens and units components of the time element "year". Legal values are from 0 to 9. M -- represents a digit used in the time element "month". The two digits in a MM format can have values from 1 to 12. D -- represents a digit used in the time element "day". The two digits in a DD format can have values from 1 to 28 if the month value equals 2, 1 to 29 if the month value equals 2 and the year is a leap year, 1 to 30 if the month value equals 4, 6, 9 or 11, and 1 to 31 if the month value equals 1, 3, 5, 7, 8, 10 or 12. h -- represents a digit used in the time element "hour". The two digits in a hh format can have values from 0 to 23. m -- represents a digit used in the time element "minute". The two digits in a mm format can have values from 0 to 59. s -- represents a digit used in the time element "second". The two digits in a ss format can have values from 0 to 60. In the formats described in this specification the whole number of seconds ·may· be followed by decimal seconds to an arbitrary level of precision. This is represented in the picture by "ss.sss". A value of 60 or more is allowed only in the case of leap seconds.

Strictly speaking, a value of 60 or more is not sensible unless the month and day could represent March 31, June 30, September 30, or December 31 in UTC. Because the leap second is added or subtracted as the last second of the day in UTC time, the long (or short) minute could occur at other times in local time. In cases where the leap second is used with an inappropriate month and day it, and any fractional seconds, should considered as added or subtracted from the following minute. For all the information items indicated by the above characters, leading zeros are required where indicated. In addition to the above, certain characters are used as designators and appear as themselves in lexical formats.

1 Proleptic - capable of anticipating and answering all possible objections.


995

996997998999

10001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037

67

68

69

http://www.w3.org/TR/xmlschema-2/#dt-may

T -- is used as time designator to indicate the start of the representation of the time of day in dateTime. Z -- is used as time-zone designator, immediately (without a space) following a data element expressing the time of day in Coordinated Universal Time (UTC) in dateTime, time, date, gYearMonth, gMonthDay, gDay, gMonth and gYear. In the lexical format for duration the following characters are also used as designators and appear as themselves in lexical formats: P -- is used as the time duration designator, preceding a data element representing a given duration of time. Y -- follows the number of years in a time duration. M -- follows the number of months or minutes in a time duration. D -- follows the number of days in a time duration. H -- follows the number of hours in a time duration. S -- follows the number of seconds in a time duration.

The values of the Year, Month, Day, Hour and Minutes components are not restricted but allow an arbitrary integer. Similarly, the value of the Seconds component allows an arbitrary decimal. Thus, the lexical format for duration and datatypes derived from it does not follow the alternative format of § 5.5.3.2.1 of [ISO 8601].

A.2. Truncated and Reduced Formats[ISO 8601] supports a variety of "truncated" formats in which some of the characters on the left of specific formats, for example, the century, can be omitted. Truncated formats are, in general, not permitted for the datatypes defined in this specification with three exceptions. The time datatype uses a truncated format for dateTime which represents an instant of time that recurs every day. Similarly, the gMonthDay and gDay datatypes use left-truncated formats for date. The datatype gMonth uses a right and left truncated format for date. [ISO 8601] also supports a variety of "reduced" or right-truncated formats in which some of the characters to the right of specific formats, such as the time specification, can be omitted. Right truncated formats are also, in general, not permitted for the datatypes defined in this specification with the following exceptions: right-truncated representations of dateTime are used as lexical representations for date, gMonth, gYear.

A.3. Deviations from ISO 8601 FormatsA.3.1. Sign AllowedAn optional minus sign is allowed immediately preceding, without a space, the lexical representations for duration, dateTime, date, gMonth, gYear.

A.3.2. No Year ZeroThe year "0000" is an illegal year value.

A.3.3. More Than 9999 YearsTo accommodate year values greater than 9999, more than four digits are allowed in the year representations of dateTime, date, gYearMonth, and gYear. This follows [ISO 8601 Draft Revision].


103810391040104110421043104410451046104710481049105010511052105310541055

105610571058105910601061106210631064106510661067

1068

106910701071

10721073

1074107510761077

1078

70

71

http://www.w3.org/TR/xmlschema-2/#ISO8601revision

http://www.w3.org/TR/xmlschema-2/#ISO8601revision

http://www.w3.org/TR/xmlschema-2/#gYear

http://www.w3.org/TR/xmlschema-2/#gYearMonth

http://www.w3.org/TR/xmlschema-2/#date

http://www.w3.org/TR/xmlschema-2/#dateTime


http://www.w3.org/TR/xmlschema-2/#gMonth


http://www.w3.org/TR/xmlschema-2/#dateTime

http://www.w3.org/TR/xmlschema-2/#duration




http://www.w3.org/TR/xmlschema-2/#ISO8601


Appendix B. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001. All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


1079

108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109

72

73

oasis€¦ · web viewthe two digits in a mm format can have values from 1 to 12. d -- represents...

Documents