Extensible Data Types (XDT®)

Version 1.0

Recommendation, July 16, 2002

Content

1. Introduction
2. Goals of the specification
3. General ideas
 3.1. Methods of control of data types
 3.2. .XDT file
 3.3. Namespaces
   3.3.1. XDT provided namespace
   3.3.2. Namespaces for user defined data types
 3.4. Scope of declared names
4. Tags supported by XDT
 4.1. Tag 'define'
 4.2. Tag 'element'
 4.3. Tag 'attribute'
 4.4. Tag 'comment'
 4.5. Tag 'include'
 4.6. Tag 'merge'
5. Attributes supported by XDT
 5.1. Attribute 'name'
 5.2. Attribute 'new-type'
 5.3. Attribute 'type'
 5.4. Attribute 'limits'
 5.5. Attribute 'pattern'
 5.6. Attribute 'occur'
   5.6.1. Designator 'e'
   5.6.2. Designator 'ch'
   5.6.3. Designator 'co'
   5.6.4. Designator 'd'
   5.6.5. Explicit omitting of content
 5.7. Attribute 'default'
 5.8. Attribute 'location'
6. Basic types predefined in XDT
 6.1. string
 6.2. integer
 6.3. float
 6.4. boolean
 6.5. date
 6.6. time
 6.7. duration
 6.8. currency
 6.9. Base64
 6.10. URI
 6.11. XML
 6.12. ext
7. Future of XTD
 Appendix A - "XDT.dtd" file
 Appendix B - example of .XDT file
 Appendix C - example of .XML file
 Appendix D - self defined data file
 Appendix D - data file included type definitions

1. Introduction

It is undoubtedly, that these days there is a huge demand to store or transfer different kind of data using XML format. This process requires well defined rules that should be simple, easy to understand by both human and computer, unambiguous, and these rules should allow to create (to define, to declare, to use) any type of complex data, needed today by vast majority of applications.
There is a lot of specifications that are trying to do this job (XML Schema, XML-RPC, and others), but unfortunately no one of them is providing a satisfactory answer to this demand, while the XML itself gives the ability to make it happened.

Present XDT specification is simple way to work with text based data. This document shows the easy way how to define different data types using XML format (web site that shows a brief comparison between XML Schema and XDT is here). As a result of applying provided and recommended here rules it is possible to generate well-formed, and valid XML document that may serve any purpose, including data exchange, data storage, etc.

XDT is based and fully compliant to XML standard version 1.0.

Present specification includes examples of .DTD files, .XDT files, instances of .XML data files. Just to simplify distinction between these examples specification uses next color convention.

Examples of .DTD files are using followed color:

<!-- File "XDT.dtd" -->
<!ELEMENT xdt:define  ((xdt:element*)|(xdt:attribute)) #IMPLIED>
<!ELEMENT xdt:element (xdt:element*) #IMPLIED>
...

Examples of .XDT files are using followed color:

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!-- File "TypeDefs.xdt" -->
<!DOCTYPE TypeDefinitions SYSTEM "XDT.dtd" [
<!ELEMENT TypeDefinitions (xdt:define) >   ]>
<TypeDefinitions xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:define new-type="tDataType" type="xdt:string"/>
</TypeDefinitions>

And finally, examples of .XML files are using this shade:

<?xml version="1.0"?>
<!-- File "Order.xml" -->
<Data xdt:type="tDataType" xdt:location="TypeDefs.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  An example of data instance file.
</Data>

2. Goals of the specification

Major goals of this specification are:

Simplify process of coding/decoding (marshalling) of data. Coded data should be easy read and be clearly understandable by both human and computer. The rules should be simple and intuitive.
To simplify process of validating and reading actual data - type definitions should closely resemble structure of corresponding data instances.
Allow to easy define and validate data that requires any desired level of type complexity.
Data coding/decoding process should be reliable and unambiguous. It should be accomplished by providing validation tools and finite, but comprehensive set of recommendations.
Specification itself, while being a complete, should be flexible and provide mechanisms to adopt new ways to work with data that will be required in future.
Facilitate the ability to use generally available and well developed XML parsers for dealing with different type of data.

There is a hope that current XDT specification achieves these goals...

3. General ideas

XML is an ideal data format for storing a structured text. At the same time - text itself may be used to represent any kind of data type. For example, an integer may be treated as a simple text with a set of constrains applied (the text should contain only numerals, and may have some signs like '-' or '+', and sometimes may have delimiters, like '.' or ',', and so on). It is possible to put additional restrictions like number of digits, used to represent the number, format or a pattern, which may specify the integer's appearance, enumerate allowable integer values, etc. Theoretically there is no limit on variety of imaginable restrictions that may be required in representing the data. Practically there is a common set of types that may be used as a basic to describe a lot of real data types and there is a common set of restrictions that may be applied to these basic types to narrow the ways how data may be (or should be) represented.

Fortunately, XML is very flexible in representing of any kind of data. It is possible (by using child/parent/siblings relationships of the elements) to create a structured data, and (by using attributes) to specify particular characteristics (a type) for each element of the data.

Current specification develops this idea into a next level. It provides simple rules of defining data types and methods how to work with data instances complying to these rules.

Generally speaking data has its own life cycle. At the very beginning structures of data should be defined by developing some specifications (type definitions). Next step - data should be collected and transformed into a desired format (accordingly to developed specifications). And finally - datum is transmitted into another place for the next storage and/or processing.

To facilitate this process XDT offers and recommends to use the followed major components:

.XDT file - as a tool for defining/declaring data types.
XDT protocol specifies methods of representing instances of structured data with different level of type control.
By declaring basic types and its characteristics XDT specifies the ways to check/validate instances of data with XDT processor.
XDT protocol allows easily to put additional restrictions on basic types making a process of representing of data to be more precise and, at the same time, more robust. It is done by providing a set of attributes.

Comparing with document type definition - DTD (it provides a way to describe a structure of XML documents in terms of elements, attributes, and data that they may contain) XDT does not require any change in syntax and structures that's distinctly different from the XML language itself. XDT is defined entirely by the native XML language.

As a standard method of specifying and coding data XDT complies to XML recommendations and it uses its own namespace.

Before defining XDT tags, attributes, basic types and looking at the examples how they may be used in a variety of practical cases let see different methods of control data types, see what is a .XDT file, and provide some guidelines how to specify namespaces.

3.1. Methods of control of data types

XDT furnishes several ways of representing datum and defining its type.

All datatype definitions are in separated .XDT file. .XML data file does not have any type definitions, but contains a reference to datatype .XDT file.
Self-type-defining method. In .XML file data instance elements itself contain its own type definitions.
Combining method - data instance .XML file includes type definitions as a separate section of the file.

First method is the most convenient in the case when there is a need to define a class of XML documents that complies with a set of defined rules. All rules are concentrated in one (or several) separated .XDT file(s) that may be taken from known place. Data instance files of this class just have a reference to the .XDT file(s). This method is useful for supporting remote service procedure calls. In this case service provider publishes .XDT file and a client takes this type definition file to compose a data instance into a request or to parse a reply data that is coming from service provider as a result of such request. If there is no change in type definition file - it may be taken only once per a bunch of service requests.
Current specification provides a lot of examples of separated type definition files and data instance files (or just fragments of them) that use these type definitions to construct its data. One of such examples of .XDT file containing type definitions is in appendix B, while appendix C shows example of data file that uses provided type definitions.

Second method allows to include type definitions into data itself, making the data a self-type-defined instance. There is no separated type definition .XDT file needed to check and/or interpret the data instance. All data elements use a set of provided by XDT attributes to specify a type of its content. Example of self-defined data instance is in appendix D. This method has advantage of not requiring a separate type definition file.

Third method represents a combination of the two methods described above. Data file includes all type definitions into the same file. It may be done directly as a section of the data file or type definitions may be included by two provided by XDT tags - 'xdt:include' or 'xdt:merge'. Example of .XML data file that contains a section defining all needed data types is in appendix E.

3.2. .XDT file

.xdt file is a type definition file. The purpose of this file is to define a class of XML documents, where each of them (an "instance document") complies to the rules, defined in this .xdt file.
.xdt file itself must comply to XML recommendations and should be validated by XDT.dtd file, that is provided by this specification. .xdt file allows to define and declare any number of data types. These definitions should be used by XDT processor or any other program that is familiar with current specification.
Find an example of .xdt file here.

3.3. Namespaces

XDT uses the same basic namespace support that been provided by XML specification.
Using namespaces is very important in expensible data types and there are two aspects that should be clarified here. First - what is a namespace for elements and attributes that are offered by XDT specification itself and how to use it. Answer should be found in the next chapter. And second, how to specify namespaces for user defined typedefinitions, elements, attributes, and how to link instances of data with these typedefinitions. See methods of using namespaces in chapter 3.3.2.

3.3.1. XDT provided namespace

To prevent namespace conflicts within documents that may use like-named structures XDT accommodates its own namespace that should be used in every .XDT file or data instance files that comply to XDT specification.
Use followed namespace declaration:

xmlns:xdt="http://xdt.gate2.net/v1.0"

Despite the fact that, accordingly to namespace rules provided for XML documents it is possible to use any namespace prefixes, to unify and simplify reading of all documents based on this specifications it is recommended to use prefix 'xdt' with all tags, attributes, and basic types described here.

3.3.2. Namespaces for user defined data types

User of this specification should follow common rules for declaring and using namespaces specified in XML. Namespace declarations allow to link typedefinitions and data itself by using references to these namespaces.

Any new name declared in a typedefinition belongs to namespace that declared by reserved attribute 'xmlns'. Below is example of declaration of default namespace with no prefix:

<xdt:xdt xmlns:xdt="http://xdt.gate2.net/v1.0"
  xmlns="http://some-domain/namespace1">
  <xdt:define new-type="tDataType" type="xdt:string"/>
</xdt:xdt>

In this example name of new type is "tDataType" and it belongs to namespace "http://some-domain/namespace1".
Followed example shows a cut from data file that uses type "tDataType" defined above.

<Data xdt:type="tDataType" xmlns:xdt="http://xdt.gate2.net/v1.0"
  xmlns="http://some-domain/namespace1">
  An example of data instance file.
</Data>

Just because element "Data" is in default namespace and this namespace is declared by attribute 'xmlns' for the element - XDT processor may find out what the type "tDataType" really is. Typedefinition for this type will be taken from the previous file that uses the same namespace as the element "Data".

It is possible to use several namespaces for typedefinitions included in one typedefinition module (file). There olny one requirement here is - data elements that uses these typedefinitions should be in the same namespace. Example below shows typedefinitions that support two target namespaces:

<xdt:xdt xmlns:xdt="http://xdt.gate2.net/v1.0"
  xmlns="http://some-domain/namespace1"
  xmlns:td="http://some-domain/namespace2">
  <xdt:define new-type="tDataType1" type="xdt:string"/>
  <xdt:define new-type="td:tDataType2" type="xdt:string"/>
</xdt:xdt>

In this example new type "tDataType1" belongs to namespace "http://some-domain/namespace1" while new type "tDataType2" belongs to another namespace "http://some-domain/namespace2". Data file that uses both types "tDataType1" and "tDataType2" that beeng defined above is here:

<Data1 xdt:type="tDataType1" xmlns:xdt="http://xdt.gate2.net/v1.0"
  xmlns="http://some-domain/namespace1">
  An example of data instance file.
</Data1>

<Data2 xdt:type="tDataType2" xmlns:xdt="http://xdt.gate2.net/v1.0"
  xmlns="http://some-domain/namespace2">
  An example of data instance file.
</Data2>

Here data elements belong to two different namespaces (despite the fact that both use default namespaces, which are different in this case). Using default namespaces is not obligatory here and it is possible to use namespace prafixes as it is permitted by XML.

Another example of whole .XDT file with namespace declaration is here. This example declares default namespace for all typedefinitions specified in the file.
Example of complete .XML file that contains data instance and comply with XDT recommendations is here. As it is atated in the previous chapter, this example has actually two namespaces. First namespace is a default namespace (declared by reserved attribute 'xmlns' with no namecpase prefix), and it is used with all data instance elements (typedefinitions). The second namespace has prefix 'xdt' (see attribute 'xmlns:xdt') and it is used with type definition elements and attribute names declared in current XDT specification.

Root element of data instance uses "xdt:type" attribute. Value of this attribute shows a reference to data's type name. As it was said earlier, if this type name does not have any name prefixes - it means that the type name is in a default namespace. XDT processor looks at the 'xmlns' attribute value to find out the default typedefinition namespace and if there is no attribute 'xdt:location' (it may specify different location that has priority here) processor takes namespace as an URI for the typedefinition resource.
If the type name has a namespace prefix (e.g. 'td:...') - XDT processor will look at the namespace declaration (in this case - 'xmlns:td' attribute). Again attribute 'xdt:location' may be used here to separate namespace for typedefinitions from an actual location of these typedefinitions.

3.4. Scope of declared names

All type definition names - declared by the attribute 'xdt:new-type' inside an element with the tag 'xdt:define' - are global. These names may be used in any place of the .XDT or .XML document. Example of nested new type definition is here. Example of defining a new type and, by doing so, declaring a new global type name in data instance file is here.

Names of elements declared by attribute 'xdt:name' may be global or local. If declaration attribute 'xdt:name' has been used with the tag 'xdt:define' - the declared name of element is global. Otherwise (the name declaration attribute is used inside elements with other than 'xdt:define' tags) they are considered to be local. It means that their purport and content depends on their position inside other elements (parent elements), and therefore element with this name can not be used out of the scope of its parent element. Names of attributes (declared inside the tag 'xdt:attribute') are always local.

4. Tags supported by XDT

XDT specification provides limited set of valid tags that may be used in type definition .XDT file. Followed table includes all supported tags with short description of the purpose of each tag as well as attributes that may be used with these tags.

Elements defining data types, elements or processing instructions
Tag	Description	Attributes	Defaults
define	Element with this tag defines a new data type and links it with the name that is declared by attribute '`new-type`', or it defines a new element with name declared by attribute '`name`'. The new type may be used directly along with some data or may be referenced in other type definitions by new type name.	`new-type, name, type, pattern, limits, occur, location, default`	`occur="1"`
element	This element may appear as a child inside '`define`' block or as a child of another '`element`' element(s). Applying of the tag allows to create structures with any desired level of complexity.	`name, type, pattern, limits, occur, location, default`	`occur="1"`
attribute	Tag defines attribute for its parent element. Element with this type must be declared inside either `define` or `element` block.	`name, type, pattern, limits, occur, location, default`	`occur="1"`
comment	Specifies the commenting element. Comment element is not treated as a data element.	`none`	`none`
include	Includes a text taken from specified location (local file, remote file, etc.). New file content will replace the element containing this tag in its present position. New file should be well-formed XML file and should not broke format of current XDT file. Attribute `location` is required here to specify URI of including resource (file).	`location`	`none`
merge	Merges content of current XDT file with XML data taken from resource specified. By default merge level depends on the current position of this element in source XDT tree. Only corresponding part of specified file will be included into (merged with) current file. Attribute `location` is required here. Attribute name may be used as a supplement to specify particular merging element.	`location, name`	`none`

In this table all required attributes are noted in bold. The rest of the attributes may or may not be present in particular element.

There is one more a supplementary tag that is defined in XDT.xdt, but is not included in the table. This is "xdt:xdt" tag and it actually provides an example of a tag that user may use as a root element in its own typedefinition files. As it is shown in appendix A the root tag may contain almost all XDT elements excluding element <xdt:attribute...>. Users may use 'xdt:xdt' tag in all typedefinition files or may declare its own root element using <!DOCTYPE root_tag ... [...]> declaration.

Next sections of the specification contains more details about usage of specific tags.

4.1. Tag 'define'

Element with this tag defines a new data type and links it with a new type name, or it may be used as a global declaration of a new data element. Attribute 'new-type' is required here for declaration of the new type name. Attribute 'name' is required for declaration of the new element's name. Either 'new-type' attribute or 'name' attribute should be present inside the 'xdt:define' tag. Declared names have global scope. The new type may be used directly with some data or may be referenced in other type definitions by specified name (see 'type' for details).
Type definitions elements (<xdt:define ...>) may appear in any place where an XML element is permitted.

List of attributes that may be used with tag 'define' contains:
new-type, type, name, pattern, limits, occur, location, default

Element with tag 'define' may be empty, may contain a data (accordingly to the 'type' attribute, if it is present), or include other child element(s). It's possible also to define attribute(s) that should be used with an element of defined type (see tag 'xdt:attribute' for details).

Here is a simplest example of 'define' element. This element defines new type tEmptyElement.

<xdt:define new-type="tEmptyElement"/>

Below is example of instance of data - element EmptyElement - that uses declared above type. Be noticed that because in type definition there is no attribute 'type' specifying a particular type of content - instance of valid data should not contain any data content either.

<EmptyElement type="tEmptyElement">
</EmptyElement>
   or just
<EmptyElement type="tEmptyElement"/>

Next example shows definition of the new "tInteger" type based on (derived from) another type (see attribute 'type' for details). Example below may be treated as a simple redefinition of already known type (in this case - 'xdt:integer') without any modification of its characteristics.

<xdt:define new-type="tInteger" type="xdt:integer"/>

It is important to be sure that base type itself does not contain references to the defined here type which may create indefinite loop of self-references. XML processor should check this case and issue an error if it happens.

Tag 'define' may be used with attributes that put additional restrictions on the type specified by the 'type' attribute. Here is an example that defines new data type "tPhoneNumber", which is based on 'xdt:string' type. Base type has been constrained to the provided pattern (see attribute 'pattern' for details):

<xdt:define new-type="tPhoneNumber" type="xdt:string"
  pattern="(\d[3])\d[3]-\d[4]"/>

An instance of data with specified type is below:

<MyPhone type="tPhoneNumber">
  (800)555-5555
</MyPhone>

Example below shows definition of the new "tIntegerPositive" data type based on earlier defined "tInteger" data type. If it is required that an element with this type should take only positive values - use attribute 'limits' here.

<xdt:define new-type="tIntegerPositive" type="tInteger" limits="0-oo"/>

If there is a necessity to set a default value for an element of this type, use attribute 'default', as shown in the next example.

<xdt:define new-type="tIsIt" type="xdt:boolean" default="yes"/>

It is important to notice that (as it was stated earlier) an element with the tag 'xdt:define' and attribute 'new-type' may be placed in any position of the XML file where an element is permitted. It means that the name declared by 'new-type' attribute is global. It is possible to put type definition element inside another type definition element in a type definition file (.XDT) or inside any data element in data instance file (.XML) creating a nested structure. It is not permitted though to use the type definition element as a root element in data instance file.

Example of nested-like type definitions is below.

(001) <xdt:define new-type="tType1">
(002)   <xdt:define new-type="tType2" type="xdt:string"/>
(003)   <xdt:element name="anElement" type="xdt:integer"/>
(004) </xdt:define>

Here is type "tType1" that contains one element "anElement" (type definition includes lines 001, 003 and 004. Second type definition defines new type "tType2" with string-type content (line 002). There is no any other relations between these two new types - "tType1" and "tType2". Particularly type "tType2" may be used without any references to the type "tType1" later.
Example of valid data instance using defined above type is here:

<SomeData1 type="tType1">
  <anElement> 123 </anElement>
</SomeData1>

<SomeData2 type="tType2">
  Any string content is here
</SomeData2>

Type definition may be placed inside any data element in a data instance file. It is an example of combined self-type-defined data file. Be noticed that parent element including such element - <xdt:define ...> is not obligated to have an element with the defined here type. Sample of a type definition inside data element is below.

(001) <Data xdt:type="tInternalDataType">
(002)   <xdt:define new-type="tInternalDataType">
(003)     <xdt:element type="xdt:integer" name="AnyNumber"/>
(004)   </xdt:define>
(005)   <AnyNumber> 12 </AnyNumber>
(006) </Data>

Instance of data with type "tInternalDataType" contains definition of the type inside its own block (lines 001, 005, and 006). Type definition of this type itself is on lines 002 - 004. It does not comprise other elements except explicitly declared one with name "AnyNumber". Actual data element with this name is on line 005.

Tag 'define' may have attribute 'occur'. It specifies number of occurrences of element itself or appearance of its content.

It is possible to use tag 'define' without 'new-type' attribute. In this case this tag defines an element with specific name (name has to be specified by attribute 'name') that can be legitimately used in data instance file.

Example of declaration of a new data element "eIDExp" is below. There is no 'new-type' attribute here.

<xdt:define name="eIDExp" type="xdt:integer" pattern="\d[8]">
  <xdt:element name="Expired" type="xdt:date"/>
</xdt:define>

Name "eIDExp" considered to be global and therefore element with this name may be used anywhere in a data instance or .XDT file.
Below is an example of a cut from .XDT file that uses the element "eIDExp":

<xdt:define new-type="tAccess">
  <xdt:element name="eIDExp"/>
</xdt:define>

XDT processor checks the name of child element against known global names and if it finds the name - as we see in this particular case - it uses it for substitution of child element with its full content taken from its definition. Result of the substitution is here:

<xdt:define new-type="tAccess">
  <xdt:element name="eIDExp" type="xdt:integer" pattern="\d[8]">
    <xdt:element name="Expired" type="xdt:date"/>
  </xdt:element>
</xdt:define>

4.2. Tag 'element'

Element with this tag declares a child element in a structure along with its name and type. Name declared inside of the element with this tag is a local name.

Type declaration elements (<xdt:element ...>) may appear inside any 'xdt:define' or another 'xdt:element' element.

List of attributes that may be used with tag 'element' contains:
name, type, pattern, limits, occur, location, default

Element with tag 'element' may be empty, may contain a data (accordingly to the 'type' attribute, if it is present), or include other elements. It's possible also to define attribute(s) that should be used with an element of defined type (see 'xdt:attribute' for details).

Here is example of usage 'element' element.

<xdt:define new-type="tClient">
  <xdt:element name="Name" type="xdt:string"/>
  <xdt:element name="Birthday" type="xdt:date"/>
</xdt:define>

Below is example of instance of data - element "Client" with the type - "tClient". It has, as defined, two elements.

<Client type="tClient">
  <Name> John Smith </Name>
  <Birthday> 1960/05/04 </Birthday>
</Client>

It is easy to create nested structures and example below shows it:

<xdt:define new-type="tPurchase">
  <xdt:element name="Client" type="tClient"/>
  <xdt:element name="CreditCard">
    <xdt:element name="CardNumber" type="xdt:integer" 
      pattern="\d[4]-\d[4]-\d[4]-\d[4]"/>
    <xdt:element name="Expiration" type="xdt:date" pattern="YYYY-MM"/>
  </xdt:element>
</xdt:define>

There is instance of data with defined type:

<Purchase type="tPurchase">
  <Client>
    <Name> John Smith </Name>
    <Birthday> 1960/05/04 </Birthday>
  </Client>
  <CreditCard>
    <CardNumber> 1234-5678-9012-3456 </CardNumber>
    <Expiration> 3001-05 </Expiration>
  </CreditCard>
</Purchase>

Tag 'element' may have attribute 'occur'. It specifies number of occurrences of element itself or appearance of its content.

4.3. Tag 'attribute'

Element with this tag declares an attribute that should be present (exception find below) in the tag of its parent element. Attribute has to have explicit type (see 'type') of its content. If there is attribute 'occur' - it may specify presence of the defined attribute.

Attribute declaration elements (<xdt:attribute ...>) may appear inside any 'xdt:define' or another 'xdt:element' element.

List of attributes that may be used with tag 'attribute' contains:
name, type, pattern, limits, occur, location, default

Element with the tag 'xdt:attribute' should not contain a child element (see XML recommendations). While it is possible to use user defined types as a base type for attribute elements - it is restricted to use user defined types, that itself may contain a child element as a part of its internal structure.

Here is example of specifying 'attribute' elements.

<xdt:define new-type="tTypeWithAttributes">
  <xdt:attribute name="color" type="xdt:string" limits="black|blue|red"/>
  <xdt:attribute name="price" type="xdt:currency"/>
  <xdt:attribute name="brand" type="xdt:string" occur="0-1"/>
  <xdt:element name="Note" type="xdt:string">
    <xdt:attribute name="brief" type="xdt:boolean"/>
  </xdt:element>
</xdt:define>

Below is example of instance of data - element "HisTie" with the type - "tTypeWithAttributes". The root element has, as defined, just one child element, two mandatory and one optional attribute. Its child element has only one mandatory attribute.

<HisTie type="tTypeWithAttributes" color="blue" price="$99.99">
  <Note brief="yes"> It's nice </Note>
</HisTie>

Despite of the fact that current XDT document does not provide any limitations on the place of 'attribute' elements among their siblings, it would be considered as a good practice to place 'xdt:attribute' elements before other elements with tag 'xdt:element'.

Tag 'attribute' may use attribute 'occur'. It specifies number of occurrences of the new defined attribute. Be noticed that designator 'e' for this attribute should allow absence or presence of the attribute no more then one time. XML does not allow XML tag to have several attributes with the same name.

4.4. Tag 'comment'

Element with this tag may keep any information that can be useful for human or a computer application. There is no constraint on content of this element except it should comply with general XML rules for constructing valid elements.

List of attributes that may be used with tag 'comment' contains:
xmlns

It is possible to specify namespace for elements used inside the tag 'comment'.

4.5. Tag 'include'

Element with this tag facilitates support of complex data projects (as element 'xdt:merge' does). To facilitate support of complex data projects XDT allows to work with data that may be spreaded in a set of separated documents. Each document may contain its own piece of data that ultimately will be included into the whole project by using elements with tag 'include'. Element of this type may be positioned in any place of XML file that may contain an element (including root element). There is only one requirement here - the name of this tag should be recognizable by XDT processor. In other words, the declaration of the namespace 'xdt:' should be done before (or at) the first usage of this tag.

List of attributes that may be used with tag 'include' contains:
location

Attribute 'location' is mandatory and it specifies the source of the data that will replace the 'include' element.

Be noticed that element with tag 'include' may be used in both type definition file and in data instance file.

Here is example of instance of data file that includes another data file:

<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="Typedefs.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:include location="ExtraData.xml"/>
</Data>

<!-- File "ExtraData.xml" -->
<DataChild>
  This element as long as its whole content will be included.
</DataChild>

  XDT processor will treat it as following file:
<!-- File "ExtraData.xml" -->
<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="Typedefs.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <DataChild>
    This element as long as its whole content will be included.
  </DataChild>
</Data>

As it is shown in this example element 'include' has been simply replaced by the content of the included file. Type of included content should comply with the type of elements expected in the place where 'include' element is. XDT processor should check it at the time when the 'include' instruction is performed.

4.6. Tag 'merge'

Element with this tag facilitates support of complex data projects (as element 'xdt:include' does).
To facilitate support of complex data projects XDT permits a work with data that may be spreaded in a set of separated documents. Each document may contain its own piece of data that ultimately will be included into the whole project by using elements with the tag 'merge'. Element with the tag 'merge' may be placed in any point of XML file that may contain an element (excluding root element).

List of attributes that may be used with tag 'merge' contains:
location, name

Attribute 'location' specifies the source of the data that will will be used to replace the 'merge' element. If there is no attribute 'location' - current file should be considered as the source. In such case attribute 'name' should specify precise position of the merging structure. Attribute 'name' may contain absolute (using root symbol '/' as a first symbol in a path - example: "/root_elem1ent/element1/merged_element") or relative (using symbol '.' as a first symbol in a path - example: "././element1/merged_element" or simply specifying its child element as a path) reference to merged element. Any element could be referred here.

XDT processor replaces the element with tag 'merge' with content taken from the specified by attribute 'location' file. The rule used with this tag is different from the case with 'xdt:include' element.
XDT processor does followed:

If there is no attribute 'name', processor takes the name of the parent element from the structure of the current position in current XML file.
Finds the first element with this name in file that has been specified by attribute 'location'. If there is not such element - an error should be generated.
Merges all child elements (as well as its content) from this location in the remote file with current element, placing them into position where element 'merge' was found.

This process looks a little bit more complicated than processing 'include' element, but it allows to merge child elements from inside of a well-formed XML file.

Be noticed that element with tag 'merge' may be used in both type definition file and in data instance file.

Here is example of instance of data file that merges with data taken from another file:

<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="MyTypes.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:merge location="ExtraData.xml"/>
</Data>

<?xml version="1.0"?>
<!-- File "ExtraData.xml" -->
<AnyOtherData xdt:type="tAnyOtherData" xdt:location="MyOtherTypes.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <Data_1>
    <Data_1-1/>
    <Data_1-2/>
  </Data_1>
  <Data>
    <Data_2-1> A content </Data_2-1>
    <Data_2-2/>
  </Data>
<AnyOtherData>

  XDT processor will treat it as following file:
<!-- File "ExtraData.xml" -->
<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="MyTypes.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <Data_2-1> A content </Data_2-1>
  <Data_2-2/>
</Data>

In this example it is assuming that the type "tData" defined in "MyTypes.xdt" file has all merged elements.

It is important to note that type of merged content should comply with the type of elements expected in the place where 'merge' element is. XDT processor should check it at the time when the 'merge' instruction is performed.
In other words, type of resulting data structure after performing the merge process should comply the required type.

If there is attribute 'name' - its value will be used as a name of the element for next search in specified by attribute 'location' file. XDT processor takes this name and then performs step 2 and 3 described in the algorithm above.
Example below uses the same file "ExtraData.xml" from the previous example, but specifies particular name of child element in it. In this case the name is "Data_1". XML processor finds first occurrence of the element with name "Data_1" and merges its content (including child elements, if such exist).

<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="MyTypes.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:merge location="ExtraData.xml" name="Data_1"/>
</Data>

  XDT processor will treat it as following file:
<!-- File "ExtraData.xml" -->
<?xml version="1.0"?>
<!-- File "Main.xml" -->
<Data xdt:type="tData" xdt:location="MyTypes.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <Data_1-1/>
  <Data_1-2/>
</Data>

Examples of .XDT files that has merging content in type definition file is below.

(001) <?xml version="1.0"?>
(002) <!-- File "TypeDefsMerging.xdt" -->
(003) <!DOCTYPE xdt SYSTEM "XDT.dtd">
(004) <xdt xmlns:xdt="http://xdt.gate2.net/v1.0">
(005)   <xdt:define new-type="tData1">
(006)     <xdt:element name="Elem1" type="xdt:string"/>
(007)     <xdt:element name="Elem2" type="xdt:integer"/>
(008)   </xdt:define>
(009)   <xdt:define new-type="tData2">
(010)     <xdt:merge name="/xdt/xdt:define/xdt:element"/>
(011)   </xdt:define>
(012)   <xdt:define new-type="tData3">
(013)     <xdt:merge name="./xdt:define/xdt:element#2"/>
(014)   </xdt:define>
(014) </xdt>
  XDT processor will treat it as following file:
(015) <xdt>
(016)   <xdt:define new-type="tData1">
(017)     <xdt:element name="Elem1" type="xdt:string"/>
(018)     <xdt:element name="Elem2" type="xdt:integer"/>
(019)   </xdt:define>
(020)   <xdt:define new-type="tData2">
(021)     <xdt:element name="Elem1" type="xdt:string"/>
(022)   </xdt:define>
(023)   <xdt:define new-type="tData3">
(024)     <xdt:element name="Elem2" type="xdt:integer"/>
(025)   </xdt:define>
(026) </xdt>

Line 010 has merge tag with no 'location' attribute and with attribute 'name' that uses absolute path. Result of performing the merge command is on line 021.
Line 013 shows similar command, but attribute 'name' uses relative path. Because element on the line 005 has two children and there is need to use the second one - name of the last element in the path is appended with array suffix '#2'.
Using of the array suffix beginning with '#' sign as an index is possible here due to XML requirements, that do not allow to use this symbol in the name of the tag itself, while the value of the attribute 'name' (see line 013) may contain such character.
There is no need to use the array suffix in case when the first element among sibling having the same name is required or there is only one element with specified name (actually it is equal to using the suffix '#1'). This case is represented on line 010, where the first element with tag 'xdt:define' (line 005), but not others tags with this name (lines 009 and 012) are requested.

Taking into consideration that name of a type defined in .XDT file by using tag 'xdt:define' is global and unique - it is possible to use this feature in narrowing the serch criteria among type definitions only. If attribute 'name' has value that begins with prefix 'typedef=' it means that value followed this prefix should be used as a search criteria for defined types.
If among 'xdt:define' elements there is an element that has attribute 'new-type' with value that is equal to the search criteria - whole content of this element should be used to merge. Example is below:

(001) <?xml version="1.0"?>
(002) <!-- File "TypeDefsMerging1.xdt" -->
(003) <!DOCTYPE xdt SYSTEM "XDT.dtd">
(004) <xdt xmlns:xdt="http://xdt.gate2.net/v1.0">
(005)   <xdt:define new-type="tData1">
(006)     <xdt:element name="Elem1" type="xdt:string"/>
(007)     <xdt:element name="Elem2" type="xdt:integer"/>
(008)   </xdt:define>
(009)   <xdt:define new-type="tData2">
(010)     <xdt:merge name="typedef=tData1"/>
(011)   </xdt:define>
(012) </xdt>
  XDT processor will treat it as following file:
(013) <xdt>
(014)   <xdt:define new-type="tData1">
(015)     <xdt:element name="Elem1" type="xdt:string"/>
(016)     <xdt:element name="Elem2" type="xdt:integer"/>
(017)   </xdt:define>
(018)   <xdt:define new-type="tData2">
(019)     <xdt:element name="Elem1" type="xdt:string"/>
(020)     <xdt:element name="Elem2" type="xdt:integer"/>
(021)   </xdt:define>
(022) </xdt>

Line 010 contains 'xdt:merge' element that has attribute 'name'. Value of this attribute begins with the prefix 'typedef=' and following part is "tData2". "tData1" datatype is defined on line 005, therefore all its content (lines 006-007) is merged into the lines 019-020.

5. Attributes supported by XDT

XDT protocol supports set of attributes, main puprose of which is to provide a mechanism of clarifying details about type definitions and valid data instances.
While set of XDT tags are more responsible for defining general structures of data, set of attributes allows to set names of elements, names of defined types, and they are more responsible for detailed specifications. Attributes described in this chapter allow to specify a base type for element's content, put additional restrictions on the base type, provide default values, and, in some cases, specify locations.
All attributes are based on 'xdt:string' type.

While it is easy by using attributes to redefine a new type form a known one (to derive a type) - it is important to remember simpler rule of overriding restrictions specified in a parent type (basic type) by attributes (if they are present here) in a new type definition.

All attributes except attribute 'limits' just override values specified in parent type.
Attribute 'limits' makes a combined mask for allowed values. It means that restrictions from the basic type should be combined with restrictions specified by this attribute (if it is present in new type definition).

Detailed descriptions for each attribute in this specification are in followed chapters.

5.1. Attribute 'name'

Attribute 'name' declares the name of an element that is associated with defined type or a name of attribute that will be used in an element of defined type. All names (start-tags) declared by this attribute should confirm to XML naming convention. All names declared by the attribute should obey common namespace rules - it means that if there is no namespace prefix been used in the attribute's value - the name is in default namespace. In a case if there is a namespace prefix - the new name is in prefix-linked namespace.

List of tags that may include this attribute:
define, element, attribute, merge

Example of usage of attribute 'name' with tag 'xdt:element' is here, with tag 'xdt:attribute' is here, and with tag 'xdt:merge' is here..

It is recommended to use attribute 'name' with tag 'xdt:element'. Especially it is important in cases when attribute 'occur' allows an element to appear more than one time at a row or to be absent at all.
Tag 'xdt:attribute' requires presence of the attribute 'name'.

Below is example of type definition that uses attribute 'name' with tag 'xdt:define', followed by valid instance of data with specified type:

<xdt:define new-type="tDataType" name="FixedName" type="xdt:string"/>

<FixedName xdt:type="tDataType">
  A text.
</FixedName>

Valid instance of "tDataType" element has the name - "FixedName" - which is declared in its type definition.

While it is possible to use attribute 'name' with tag 'xdt:define', current specification does not recommend it. It forces that an element with defined type should have specific name (tag) that can not be changed in data instance.

If attribute 'name' is omitted in a type definition, it means that that particular element confirming that type in a data instance may have any name. Example of type definition is below, followed by example of valid data instance based on this type:

<xdt:define new-type="tDataType">
  <xdt:element type="xdt:integer"/>
</xdt:define>

<Data xdt:type="tDataType">
  <AnyNumber> 12 </AnyNumber>
</Data>

In this example the name of child element is not defined in initial type definition for "tDataType". Therefore in a data instance file it is permitted to use any name for it, and in this particular example the name of the child element is "AnyNumber". Not specifying the name of a child element is not recommended in the case when attribute 'occur' changes element's default appearance.

5.2. Attribute 'new-type'

Attribute 'new-type' is used in elements with tag 'xdt:define'. It declares a name of the new defined type. The name of the type should confirm to XML naming convention, and it must be unique (see scope of declared names here). Namespace of the new type depends on a namespace prefix. If it is present in front of the name - new name belongs to the specified by the prefix namespace. If there is no prefix - new type name is in default namespace.

List of tags that may include this attribute:
define, DataTag

Examples of usage of attribute 'new-type' with tag 'xdt:define' are here and here.

5.3. Attribute 'type'

Attribute 'type' - as it comes from the name - specifies type of the element's content. In the current specification type definitions are based on the simple idea of deriving types from some known type (XDT predefined or user defined). Other attributes may apply additional restrictions on this base type (if it is required).
In a data instance attribute 'type' along with other attributes specifies the particular type of the data, providing the right way to check and/or interpret that data by XDT processor.

List of tags that may include this attribute:
define, element, attribute, DataTag

Notice that if defined type (or element) does not have attribute 'type' - it means that element with this type does not have a data content at all (but may have child element(s), if they are declared in its type definition).
Example of simple redefinition of known type (in this case - 'xdt:integer') with tag 'xdt:define' is here.
Example of usage already defined by user type (in this case "tClient") with the 'type' attribute and 'xdt:element' tag is here.

Here is another example of usage 'type' attribute. In this case 'type' attribute refers to user defined type "tSomeChoices". Base type "tSomeChoices" is modified here by attribute 'occur' with designator 'ch' type element.

<xdt:define new-type="tSomeChoices">
  <xdt:element name="FirstChoice" type="xdt:boolean" occur="ch"/>
  <xdt:element name="SecondChoice" type="xdt:integer" default="5" occur="ch"/>
</xdt:define>

<xdt:define new-type="tNewChoices">
  <xdt:element name="FirstTwoChoices" type="tSomeChoices" occur="ch"/>
  <xdt:element name="ThirdChoice" occur="ch"/>
</xdt:define>

Examples of valid instances of this type are below.

<ChoiceData1 type="tNewChoices">
  <FirstTwoChoices>
    <FirstChoice> 1 </FirstChoice>
  </FirstTwoChoices>
</ChoiceData1>
  another valid data example:
<ChoiceData2 type="tNewChoices">
  <ThirdChoice/>
</ChoiceData2>

The next example shows usage of attribute 'type' in defining type of 'xdt:attribute' content.

<xdt:define new-type="tElementWithAttribute">
  <xdt:attribute name="color" type="xdt:string" limits="red|blue"/>
  <xdt:attribute name="time" type="xdt:time" pattern="hh/mm"/>
</xdt:define>

Example of valid instance of this type is right here.

<ElementAndAttributes type="tElementWithAttribute" color="blue" time="12:55"/>

Element "ElementAndAttributes" with type "tElementWithAttribute" has two attributes that are based on 'xdt:string' and 'xdt:time' types respectively.

Be notices that derived type (specified by the 'type') for attributes can not have a child element inside. Only text content is allowed here (see tag 'xdt:attribute' for more details).

Below is example of usage of attribute 'type' in a data instance file. Data instance refers to the type "tCustName" that has been defines in type definition file "SomeType.xdt". Attribute 'location' specifies a direction needed to reach resource (usually a type definition .XDT file) as well as resource itself.

<?xml version="1.0"?>
<!-- File "SomeType.xdt" -->
<!DOCTYPE TypeDefinitions SYSTEM "XDT.dtd">
<xdt xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:define new-type="tDate" type="xdt:date"/>
</xdt>

<?xml version="1.0"?>
<!-- File "Congratulations.xml" -->
<EndOfYear xdt:type="tDate" xdt:location="SomeType.xdt"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  2002/12/31
</EndOfYear>

Due to the fact that XDT uses its own namespace that differs from target namespace it is possible to put type definitions into data instance file. In this case attribute 'location' may, by obvious reason, be omitted. See example of data instance file that combines both type definition and actual data specification.

<?xml version="1.0"?>
<!-- File "HappyNewYear.xml" -->
<EndOfYear xdt:type="tDate"
  xmlns:xdt="http://xdt.gate2.net/v1.0">
  <xdt:define new-type="tDate" type="xdt:date"/>
  2002/12/31
</EndOfYear>

Type definition of new type "tDate" has been placed inside data element "EndOfYear" with this type.

5.4. Attribute 'limits'

Attribute 'limits' allows to control the acceptable values that can be used with datatypes. It specifies all permissible values that may occur in an instance of data complying with the type.

List of tags that may include this attribute:
define, element, attribute

Because the attribute limits puts restrictions on the type specified by attribute base, presence of attribute limits in the case if there is no attribute base is useless and should be treated as a warning or error by XDT processor.

Reaction of XDT processor may depend on the base type specified by 'type' attribute. Below are several tables describing symbols and rules that are used with particular base types.

Attribute 'limits' with type="xdt:integer", type="xdt:float", and type="xdt:currency"
Symbol(s) Description Examples

min-max It is a range symbol (do not confuse it with minus sign). This symbol specifies the range of allowed values between min and max margins. min and max values are included in the range if otherwise is specified (see '{}' below in this table). min value should be on the left side of the symbol and max should be on the right. It is permissible that min is equal to max. 0-5
15-43

| Pipe symbol or choice indicator. Both values (from its left side as well as from its right side) are allowed. Use of pipe indicator facilitates enumerating a finite set of values that can be used in valid instances of data. 0-5|10-15

oo Simply an infinite. If it is used on the right side of delimiter - it is the same as +oo. Be noticed that in the second example there is range symbol, and because there is rule that right side of this symbol should contain max value - symbol -oo should be treated as symbol +oo rather then symbol -oo. oo,
0-oo

-oo Negative infinite. This symbol should not be used on the right side of range symbol (as max value). Example specifies that all negative values are allowed. -oo-0

+oo Positive infinite. This symbol should not be used on the left side of range symbol (as min value). First example specifies a range of possible values and it includes all positive values that more then 5 (including 5 as well). Second is redundant and it is equivalent to 5-oo. 5-oo, or
5-+oo

{} Curly brackets enclose values or range of values that are restricted.
First example allows all positive values excluding 0. The second one permits all integer values excluding 5 and 10. {0}-oo,
{5}|{10}

Set of examples below shows possible usage of attribute 'limits' in putting some restrictions on possible values of integer data.

Attribute '`limits`' with `type="xdt:integer"`, `type="xdt:float"`, and `type="xdt:currency"`
Symbol(s)	Description	Examples
min-max	It is a range symbol (do not confuse it with minus sign). This symbol specifies the range of allowed values between min and max margins. min and max values are included in the range if otherwise is specified (see '{}' below in this table). min value should be on the left side of the symbol and max should be on the right. It is permissible that min is equal to max.	0-5 15-43
\|	Pipe symbol or choice indicator. Both values (from its left side as well as from its right side) are allowed. Use of pipe indicator facilitates enumerating a finite set of values that can be used in valid instances of data.	0-5\|10-15
oo	Simply an infinite. If it is used on the right side of delimiter - it is the same as +oo. Be noticed that in the second example there is range symbol, and because there is rule that right side of this symbol should contain max value - symbol -oo should be treated as symbol +oo rather then symbol -oo.	oo, 0-oo
-oo	Negative infinite. This symbol should not be used on the right side of range symbol (as max value). Example specifies that all negative values are allowed.	-oo-0
+oo	Positive infinite. This symbol should not be used on the left side of range symbol (as min value). First example specifies a range of possible values and it includes all positive values that more then 5 (including 5 as well). Second is redundant and it is equivalent to 5-oo.	5-oo, or 5-+oo
{}	Curly brackets enclose values or range of values that are restricted. First example allows all positive values excluding 0. The second one permits all integer values excluding 5 and 10.	{0}-oo, {5}\|{10}

<xdt:define new-type="tInteger">
  <xdt:element name="case_1" type="xdt:integer" limits="1|2|3" occur="ch"/>
  <xdt:element name="case_2" type="xdt:integer" limits="0-oo" occur="ch"/>
  <xdt:element name="case_3" type="xdt:integer" limits="3-5|10-15" occur="ch"/>
  <xdt:element name="case_4" type="xdt:integer" limits="-5--3" occur="ch"/>
  <xdt:element name="case_5" type="xdt:integer" limits="-3-10" occur="ch"/>
  <xdt:element name="case_6" type="xdt:integer" limits="0-5|{3}" occur="ch"/>
</xdt:define>

Here is a brief description of specified above limitations on the basic 'integer' type.
Element "case_1" should have content which has value - either 1, or 2, or 3.
Element "case_2" should have content which may have any positive value (including zero).
Element "case_3" should have content which may have value - either in range from 3 to 5 (including 3 and 5) or in the range between 10 and 15.
Element "case_4" should have content which may have value between minus 5 and minus 3.
Element "case_5" should have content which may have value between minus 3 and plus 10.
Element "case_6" should have content which may have value in a range between 0 and 5, but not equal to 3.

Attribute '`limits`' with `type="xdt:string"` and other string-based user defined types.
Symbol(s)	Description	Examples
\|	Choice indicator. Either one of the two (or several) values is allowed (but not two of them). Choice indicator may be iterated any time allowing only one element from the list of possible choices. If there is a need to change or replace standard choice indicator - place old choice indicator first, followed by a new one. The last example shows this method.	bolt\|nut\|washer \|:a:b:c
[]	Set of permitted characters (not words). Symbol dash ('`-`') may be used to specify a range between two margins (both margin values are included into the range). If the permission indicator has been used - only specifically mentioned symbols and characters are allowed in a data string (others values are restricted by default). Example shows that only characters in upper and lower case are permitted in a data content.	[A-Z]\| [a-z]
{}	Curly brackets enclose values or range of values that are restricted. In the example strings "war" and "fight" are restricted. It is possible to specify set of restricted characters/symbols by using combination of `[]` and `{}` specificators. Second example shows restriction to use '`a`', '`b`' and '`c`' characters as well as its all upper case equivalents.	{war}\|{fight} {[abc]}\|{[A-C]}

In the case when it is requires to restrict some particular characters from the data instance based on 'xdt:string' datatype - it is recommended to specify them in a hexadecimal form beginning with symbol '#'. Example below shows putting a restrictions on symbols: tabulation (#x9), carriage return (#xD), and line feed (#xA).

<xdt:define new-type="tNormalizedString" type="xdt:string"
  limits="{#x9}|{#xD}|{#xA}"/>

Attribute 'limits' with type="xdt:date", type="xdt:time", and type="xdt:duration"
Symbol(s) Description Examples

min-max Has the same meaning as for 'xdt:integer' type. Values should have default format (see default formats for 'xdt:date' and 'xdt:time' types). 2002/05/23-2003/01/14,
8:30-17:10

| Pipe symbol or choice indicator. Both values (from the left side as well as from the right side) are allowed. 14:00|15:00

oo Has the same meaning as for 'xdt:integer' type. Values should have default format (see default formats for 'xdt:date' and 'xdt:time types). 0 here has special meaning - it represents current date or current time. oo,
0-oo

-oo See description for oo symbol here. -oo-0

+oo See description for oo symbol here. 1800/01/01-oo,
0-+oo

{} Curly brackets enclose values or range of values that are restricted.
First example permits dates for whole 2000 year. The second example restricts time between 13:00 and 14:00 and 18:00 and 8:00. 2000/01/01-{2001/01/01},
{13:00-14:00}|{18:00-8:00}

Attribute '`limits`' with `type="xdt:date"`, `type="xdt:time"`, and `type="xdt:duration"`
Symbol(s)	Description	Examples
min-max	Has the same meaning as for '`xdt:integer`' type. Values should have default format (see default formats for '`xdt:date`' and '`xdt:time`' types).	2002/05/23-2003/01/14, 8:30-17:10
\|	Pipe symbol or choice indicator. Both values (from the left side as well as from the right side) are allowed.	14:00\|15:00
oo	Has the same meaning as for '`xdt:integer`' type. Values should have default format (see default formats for '`xdt:date`' and '`xdt:time` types). 0 here has special meaning - it represents current date or current time.	oo, 0-oo
-oo	See description for oo symbol here.	-oo-0
+oo	See description for oo symbol here.	1800/01/01-oo, 0-+oo
{}	Curly brackets enclose values or range of values that are restricted. First example permits dates for whole 2000 year. The second example restricts time between 13:00 and 14:00 and 18:00 and 8:00.	2000/01/01-{2001/01/01}, {13:00-14:00}\|{18:00-8:00}

Find example of usage of attribute 'limits' with 'xdt:time' type of data here.

Attribute 'limits' with type="xdt:URI" and type="xdt:ext"
Symbol(s) Description Examples

| Pipe symbol or choice indicator. Both values (from the left side as well as from the right side) are allowed. http://www.anyaddress1.com|http://www.anyaddress1.com

{} Curly brackets enclose values or range of values that are restricted.
{http://some-bad-site.com}

Attribute '`limits`' with `type="xdt:URI"` and `type="xdt:ext"`
Symbol(s)	Description	Examples
\|	Pipe symbol or choice indicator. Both values (from the left side as well as from the right side) are allowed.	http://www.anyaddress1.com\|http://www.anyaddress1.com
{}	Curly brackets enclose values or range of values that are restricted.	{http://some-bad-site.com}

By using attribute 'limits' it is possible to specify particular values from the predefined set for 'xdt:boolean' basic type.

Attribute 'limits' may put restriction on the size of the binary data specified by the basic type 'xdt:Base64'. It may define maximum number of octets (8 bits) of binary data.

5.5. Attribute 'pattern'

Attribute 'pattern' is very useful tool to specify a new format for type based on 'xdt:string' or change default format for some predefined types. It is a simple way to force an instance of text content to fit a certain pattern.

List of tags that may include this attribute:
define, element, attribute

Type of value of attribute 'pattern' itself is a string. This is a common string that may include escape characters that put additional details on the format. All escape characters begin with symbol '\' followed by one or more specifiers. In a data with specified type it should be replaced with text containing some data that formatted accordingly to the escape description. See followed table for the list of escape characters allowed in current specification.

Escape characters
Character(s)	Description
\\	Back slash '\' itself is in an instance of data.
\[	Open bracket '[' is in an instance of data.
\{	Open curly brace '{' is in an instance of data.
\a	A character is in an instance of data.
\a[n]	'n' characters are in an instance of data (where 'n' is a number of characters).
\i	An integer is in an instance of data. No additional restrictions applied.
\i[n]	An integer is in an instance of data. It contains exactly 'n' digits.
\i{n.m}	An integer is in an instance of data. Integer should be formatted with 'n' digits, followed by '.', followed by 'm' digits.
\f	A number in exponential notation is in an instance of data. No additional restrictions applied.
\f{n.mEk}	A number in exponential notation is in an instance of data. Value should be formatted with 'n' digits, followed by '.', followed by 'm' digits, followed by letter 'E' (or 'e'), followed by 'k' digits of power.

It is possible to specify a range of permitted values instead of exact number (n) in followed cases:

number of characters in \a[] expression
number of digits in \i[] expression

To do so use a range like this: [a-b]. Where 'a' and 'b' are sequentially minimum and maximum numbers of characters (digits) allowed.

Find examples of usage of attribute 'pattern' with followed types of data: 'integer', 'float', 'time', 'date', 'duration'.

5.6. Attribute 'occur'

Attribute specifies how many times the element itself may appear in a parent element and/or number of time that data with specified type may occur in the content of the element. This is a powerful attribute that is useful to allow element itself to be omitted, to be present number of times (creating an array of elements), to allow create a choice, and to allow element's content to be omitted or to be present specified number of times, creating an array of data instances with some specific type.

List of tags that may include this attribute:
define, element, attribute

Default value for this attribute is 'occur="1"' (to be more precise it is "e=1,co=1,d= "), which means that element should appear only once and in should have content with specified type (if there is no type specification - content should be omitted).

There is a set of designators (additional specificators) that may be used along with this attribute: 'e', 'ch', 'co', and 'd'. There is no strict requirement for an order in which designators may appear as a value of attribute 'occur'. Delimiter between these designators is ',' (comma).

If there is no any specific designator used inside a value for the attribute 'occur' - it means that attribute specifies a number how many times the element itself may appear as a child element inside the block of its parent element. The specification in this case equals to usage of designator 'e' (see details below).

Generally speaking the number of element's occurrences has to be specified in a way similar to one that is used with attribute 'xdt:limits'. It may have a single value that specifies exact number (for example "3", it means - element must appear 3 times), it may be a range of possible numbers (example - "1-5"), or it may be a set of ranges (example - "1-3|5-8").

5.6.1. Designator '`e`'

Designator 'e' should be used to specify the number of times element itself should/may appear. As all other designators it used in form "e=n", where 'e' states for element's designator, and 'n' is its value. As stated above, designator 'e' is a default one and if there is no another designators required with attribute 'occur' - it may be omitted. Below see examples, where attribute 'occur' specifies the way how the element itself with specified type has to occur in a data instance.

<define new-type="tMayBeOmitted" type="xdt:integer" occur="0-2"/>

<define new-type="tSomeType">
  <element name="Element1" type="xdt:string" occur="1-3"/>
  <element name="Element2" type="xdt:date" occur="e=0-1"/>
</define>

In the first example element with the type "tMayBeOmitted" may be omitted or may be present as a child element, but no more then 2 times. In element with the type "tSomeType" first child element should be present at least once, but no more then 3 times, while child element with the name "Element2" may be omitted at all or may occur just once. In the last example there is designator 'e' that has been used to clarify number of occurrence of element itself. Strictly speaking in this example 'e' may be omitted (as a default value, and previous examples show the case), but still be present here for the demonstration purpose only.

5.6.2. Designator '`ch`'

Designator 'ch' should be used to specify the choice among similar elements. If there is another element (or elements) with the attribute 'occur' that has designator 'ch' and this element is (or they are) sibling(s) - the only one of them is allowed (and should) to be present in an instance of valid data with specified type.
Designator may do not have a value (it is a simplest case, default value), or it may specify particular choice where it participates. In this case only one element among similar sibling elements having the same value of designator 'ch' will be valid in data instance structure. This feature allows several choices to be present inside one parent element.

Examples of type definition file that uses attribute 'occur' with designator 'ch' are below.

<define new-type="tParentWithChoiceChilds1">
  <element name="Element1" type="xdt:string" occur="ch"/>
  <element name="Element2" type="xdt:string" occur="ch"/>
  <element name="Element3" type="xdt:string" occur="ch="/>
</define">

<define new-type="tParentWithChoiceChilds2">
  <element name="Element1" type="xdt:string" occur="ch=a"/>
  <element name="Element2" type="xdt:string" occur="ch"/>
  <element name="Element3" type="xdt:string" occur="ch=a"/>
  <element name="Element4" type="xdt:string" occur="ch=pref"/>
  <element name="Element5" type="xdt:string" occur="ch=pref"/>
  <element name="Element6" type="xdt:string" occur="ch="/>
</define">

First type definition ("tParentWithChoiceChilds1") has three child elements. All of them have attribute 'occur' with designator 'ch' that has the same default value ('ch' and 'ch=' are considered equal). Data element with this type will have only one element among the whole group. It may be either "Element1", or "Element2", or "Element3".
Second type definition ("tParentWithChoiceChilds2") has three groups of independent choices: default choice ("Element2" or "Element6"), choice 'a' ("Element1" or "Element3"), and choice 'pref' ("Element4" or "Element5"). Data element with this type will have three elements, each one representing one particular group.
Examples of valid data instances that uses these types are below.

<ParentWithChoiceChilds1 type="tParentWithChoiceChilds1">
  <Element2> a data </Element2>
</ParentWithChoiceChilds1>

<ParentWithChoiceChilds2 type="tParentWithChoiceChilds2">
  <Element3> data 3 </Element3>
  <Element4> data 4 </Element4>
  <Element6> data 6 </Element6>
</ParentWithChoiceChilds1>

In a data instance choice elements should appear in the same order that is specified in its corresponding type definition.

If type definition contains only one element with attribute 'occur' that specifies a particular choice designator (there is no other sibling with the same choice) XDT processor should generate a warning.

If at least one of the sibling elements among the same choice group has designator 'e' that allows to omit the element (for example 'occur="e=0-1,ch"') it is permitted that data instance with new type specified may do not have a data element representing this group.
Example of type definition is here:

<xdt:define new_type="tChoiceThatMayBeOmitted">
  <element name="Element1" type="xdt:string" occur="ch,e=0-1"/>
  <element name="Element2" type="xdt:string" occur="ch"/>
</xdt:define>

A valid data element with specified above type may do not have a child element at all. It comes from the logic: here the child element "Element1" has been chosen among the group of choice elements and in this particular case it is simply omitted. A data element in other occasions still may contain "Element1" or "Element2" as its child element, as usual.

It is permitted to create a group of elements that have different base types for its contents. In this case it is required to use attribute 'name' to specify name of each element in the group allowing to XDT processor to validate provided type and parse data accordingly to it.
See example of such type definition below:

<xdt:define new_type="tChoiceAmongDifferentTypes">
  <element name="aString" type="xdt:string" occur="ch"/>
  <element name="anInteger" type="xdt:integer" occur="ch"/>
  <element name="aDate" type="xdt:date" occur="ch"/>
</xdt:define>

Valid data instance with specified type is here:

<anElement type="tChoiceAmongDifferentTypes">
  <anInteger> 12345 </anInteger>
</anElement>

It is easy to create nested structures (as it is possible to do with 'element') and example below shows it:

(001) <xdt:define new-type="tNestedChoices">
(002)   <xdt:element name="FirstChoice" type="xdt:string" occur="ch"/>
(003)   <xdt:element name="SecondChoice" occur="ch">
(004)     <xdt:element name="case_1" type="xdt:integer" occur="ch"/>
(005)     <xdt:element name="case_2" type="xdt:date" occur="ch"/>
(006)   </xdt:element>
(007) </xdt:define>

There are two different groups of elements using default choice name. First group includes elements on lines 002 and 003, while the second group comprises elements on the lines 004 and 005. There is no crossing among elements of these two groups because they are on different levels of parent/child relationship. Valid instances of data with defined type are below:

<TheChoice1 type="tNestedChoices">
  <FirstChoice>
    This is example of choosing the FirstChoice element
  </FirstChoice>
</TheChoice1>
  or this one
<TheChoice2 type="tNestedChoices">
  <SecondChoice>
    <case_1> 12345 </case_1>
  </SecondChoice>
</TheChoice2>
  or even this one
<TheChoice3 type="tNestedChoices">
  <SecondChoice>
    <case_2> 01/23 </case_2>
  </SecondChoice>
</TheChoice3>

Be noticed that by default attribute 'occur' does not have designator 'ch'. It means that element does not belong to any choice group if there is specific 'ch' designator used.

5.6.3. Designator '`co`'

Designator 'co' rules how a content of the element should occur. It allows flexible way for new content description. Value of the designator declares a number of times that content with specified type may be repeated inside the element. This designator allows to support array of data sub-elements with the same type as a whole element's content.

Example of type definition is here:

<define new-type="tArray4Int" type="xdt:integer" occur="co=4"/>

Valid data instance that use type definition declared above is here:

<Arr4Integers type="tArray4Int"> 1 2 3 4 </Arr4Integers>

Type "tArray4Int" declares that element with this type must have array of 4 integer values as its content. There is no need to specify a delimiter (see next chapter), that is different from the default - white space. It is because XDT processor can easily separate every integer value from the others.

5.6.4. Designator '`d`'

'd' declares delimiter that should be used in case when multiple (more than one) data sub-elements are required to form the whole content of the element (see designator 'co'). This delimiter must be used in data instance to separate each sub-element in the array. Any character may be chosen as the delimiter with one and obvious restriction - delimiter should not be present in any data of sub-element itself.

Delimiter 'd' may be omitted in the case when each element of the array has type allowing clear distinction between them (like integer, or a token, or a date element, etc.). In this case a white space places the role of default value for 'd' designator.

Example of type definition is here:

<define new-type="tArrayStrWithDelimeter"
  type="xdt:string" occur="co=3,d=,,e=1"/>

This example shows that content of an element with the type "tArrayStrWithDelimeter" has to have three sub-elements each with type 'xdt:string' and there is delimiter ',' that should be used in the instance. Be noticed here that the first comma following immediately after 'd=' specifies new delimiter to be used between data sub-elements, while the second one is just a regular delimiter between designators.
Valid data instance that complies the type definition declared above is here:

<StringsWithDelimiter type="tArrayStrWithDelimeter">
  first string, second string, third string
</StringsWithDelimiter>

5.6.5. Explicit omitting of content

XDT specification requires that, if an element does have a particular content type declaration, valid data instance should contain the data accordingly to this type. If there is no content with specified type and there is no attribute 'default' - XDT processor should generate an error.

If element must do not have a data content at all - simply do not use 'type' attribute to specify a base type.
In the case, when, for some data element, presence of its content with declared type is not strictly required (or may be omitted) - attribute 'occur' should specifically say about it.

Below is an example that shows type of data that may do not have a content with specified type.

<define new-type="tContentIsNotRequired"
  type="xdt:boolean" occur="co=0-1"/>

Two examples of valid data instances with the same specified type are here:

<Element1 type="tContentIsNotRequired"/>
  or this one
<Element2 type="tContentIsNotRequired">
  true
</Element2>

First element "Element1" is empty one, while the second "Element2", that uses the same type, contains a boolean type data.

5.7. Attribute 'default'

As it comes from its name, attribute specifies a value of defined type that should be used by XDT processor in the case if instance of data does not actually contain a content (is empty).

List of tags that may include this attribute:
define, element, attribute

There is no default value specified for this attribute.

A value of default attribute should correspond to the defined type. All attributes that put some restrictions should be taken into consideration when declaring default value.

Examples of the definitions with using of attribute 'default' are here:

<define new-type="tDefault1" type="xdt:boolean" default="true"/>
<define new-type="tDefault2" type="xdt:string"
  limits="red|yellow|green" default="green"/>
<define new-type="tDefault3" type="xdt:date"
  pattern="YY/MM" default="02/12"/>

First example defines type "tDefault1". If an instance of data element with type "tDefault1" is empty XML processor should provide default value (which in this case is 'true') as its content. The same is true about second and the third example.

If type definition element contains derived type specification (see attribute 'type'), and there is no attribute 'default', and there is no attribute 'occur' with designator 'co' explicitly specifying that content may be omitted - XDT processor should generate an error in a case if a data instance of this type does not contain its defined content.

5.8. Attribute 'location'

This attribute specifies the resource (URI, remote or local URL or URN) that will be taken by XDT processor to perform some actions.

List of tags that may include this attribute:
define, element, attribute, include, merge

Attribute 'location' used with elements 'xdt:define', 'xdt:element', 'xdt:attribute' specifies a resource containing definition that is referred by attribute 'type', which is necessary companion for the attribute 'location' in this case.
Attribute 'location' has special meaning if it used with basic type 'xdt:ext' that supports new type extensions.

Attribute 'location' used with elements 'xdt:include' and 'xdt:merge' specifies the resource used for corresponding action.

URLs in form 'path/file' are located relative to the current directory, while URLs in form '/path/file' are located relative to the root directory for the server or current file system. If only a filename is specified by this attribute - the resource expected to be in the same directory as the associated XML document.

Example of applying of this attribute with attribute 'type' is here, with tag 'xdt:include' is here, and with tag 'xdt:merge' is here.

6. Basic types predefined in XDT

XDT provideswith a set of predefined basic types.
The tables below shows which of these basic types may be modified by using attributes (facets) defined in this specification.

Basic types and attributes
Basic types	XDT attributes
Basic types	`name`¹	`new-type`¹	`type`¹	`limits`	`pattern`	`occur`	`location`	`default`²
`string`	-	-	-	+	+	+	-	+
`integer`	-	-	-	+	+	+	-	+
`float`	-	-	-	+	+	+	-	+
`boolean`	-	-	-	+	-	+	-	+
`date`	-	-	-	+	+	+	-	+
`time`	-	-	-	+	+	+	-	+
`duration`	-	-	-	+	+	+	-	+
`currency`	-	-	-	+	+	+	-	+
`Base64`	-	-	-	+	-	-	-	-
`URI`	-	-	-	-	-	-	+	+
`XML`	-	-	-	-	-	+	-	+
`ext`	-	-	-	-	-	+	+	+

¹ - attributes 'name', 'new-type', and 'type' do not actually modify derived type. They just declare a name of element, name of new type, and name of base type.
² - attribute 'default' does not change characteristics of the defined type, providing the default value for the data instance that created with this type.

More detailed information about predefined basic types are in chapters below.

6.1. string

An element with type 'xdt:string' can be any text allowed as an XML content. It may contain any characters except less then symbol ('<') and the ampersand symbol ('&').

List of attributes modifying this type:
limits, pattern, occur

An example of the element with type 'xdt:string' is here:

<TextData type="xdt:string">
  This is any kind of text allowed in XML document.
</TextData>

6.2. integer

An element with type 'xdt:integer' can be any whole number that is positive, negative, or zero (for representing a floating point data see type 'xdt:float' for details).

List of attributes modifying this type:
limits, pattern, occur

An example of the element with type 'xdt:integer' is here:

<IntegerData type="xdt:integer">
  1234567890
</IntegerData>

Delimiters (in this case ',') in data instances could be omitted.

It is possible to specify particular format used by integer type of data by using 'pattern' string. Default pattern string is simple - "-1". It requires that data instance should have at least one digit and in the case of negative value this digit should be preceded by negative sign - "-".

In the case when specific delimiter is required - put it as first character in 'pattern' string. Example below shows "," sign as the delimiter.

<IntegerDataDelim type="xdt:integer" pattern=",-1">
  1,234,567,890
</IntegerDataDelim>

While there is no limit for maximum number of digits used for representing an integer, it is accomplishable to clarify minimum number of the digits by putting positive number 'n' into format string. If the number of digits in the output value is less than the specified by 'n' width, zeroes are added to the left side of the integer.

<IntegerData1 type="xdt:integer" pattern="5">
  00123
</IntegerData1>

Negative sign is required for all negative values. Positive sign preceding (or following, see below) an integer is not required, but may be forced by putting '+' sign into a 'pattern' string (replacing the negative sign "-"). In this case either '-' or '+' sign will precede number in any case.

<IntegerData2 type="xdt:integer" pattern="+5">
  +00123
</IntegerData2>

Displaying negative numbers in some countries is different. Instead of the negative sign (-) appearing at the beginning of the number, the negative sign (-) may instead appear at the end of the number. Alternatively, you can display the number with parentheses around. Thus a negative one one hundred twenty-three could be displayed as:

<IntegerNegative1 type="xdt:integer">
  -123
</IntegerNegative1>
<IntegerNegative2 type="xdt:integer" pattern="1-">
  123-
</IntegerNegative2>
<IntegerNegative3 type="xdt:integer" pattern="(1)">
  (123)
</IntegerNegative3>

If the base of positional number system differ from 10 it should be specified by sigh '@' followed with the new base. See examples for representing hexadecimal and binary data respectively:

<IntegerData3 type="xdt:integer" pattern="2@16">
  0F
</IntegerData3>
<IntegerData4 type="xdt:integer" pattern="5@2">
  000110
</IntegerData4>

6.3. float

An element with type 'xdt:float' can be any floating-point number that is positive, negative, or zero.

List of attributes modifying this type:
limits, pattern, occur

Examples of the elements with type 'xdt:float' are here:

<FloatData1 type="xdt:float"> 3.6 </FloatData1>
<FloatData2 type="xdt:float"> -5.4e+9 </FloatData2>

If there is a need to have a particular format of data with float type it is may be done by using 'pattern' string. Examples are below.

<FloatData3 type="xdt:float" pattern="+3.2"> 
  +003.60 </FloatData3>
<FloatData4 type="xdt:float" pattern="2.1e+2">
  -05.4e+09 </FloatData4>

'pattern' string may specify required delimiters (both thousands separator and decimal separator or just one decimal separator). Examples below show this cases. If there is a need to have a particular format of data with float type it is may be done by using 'pattern' string. Examples are below.

<FloatData5 type="xdt:float" pattern=",+3.1"> 
  +123,456.6 </FloatData5>
<FloatData6 type="xdt:float" pattern=".1,1E+2">
  -123.456,4E+00 </FloatData6>

"FloatData6" has thousands separator ".", while using decimal separator ",".

Note that this specification recommends to use normalized representation of scientific notation, where there is no more then one digit to the left of the decimal point (decimal delimiter - to be more precise) and it must have at least one digit on the right of the decimal point. Leading and trailing zeroes should be omitted. Example of right scientific format is below.

<FloatData7 type="xdt:float" pattern="-1.1E-1"> 
  1.0E2 </FloatData7>
<FloatData8 type="xdt:float" pattern="-1.1E-1">
  -1.234E-4 </FloatData8>

6.4. boolean

An element with type 'xdt:boolean' can be can be represented only by two possible values - 'true' (which may be substituted by '1' or 'yes'), or 'false' (which may be substituted by '0' or 'no').

List of attributes modifying this type:
limits, occur

Examples of the elements with type 'xdt:boolean' are here:

<BoolY1 type="xdt:boolean"> true </BoolY1>
<BoolY2 type="xdt:boolean"> 1 </BoolY2>
<BoolY3 type="xdt:boolean"> yes </BoolY3>
<BoolN1 type="xdt:boolean"> false </BoolN1>
<BoolN2 type="xdt:boolean"> 0 </BoolN2>
<BoolN3 type="xdt:boolean"> no </BoolN3>

If there is a need to use particular values form the set provided above - use 'limits' attribute. Example:

<BoolYes type="xdt:boolean" limits="yes|no"> yes </BoolYes>

6.5. date

An element with type 'xdt:date' can be any date-formatted string.

List of attributes modifying this type:
limits, pattern, occur

Default format string is "YYYY/MM/DD". Where:
YYYY - year (any integer with number of digits no less then 4),
MM - month (1 - 12),
DD - day (1 - 31, or less for certain months)

It is possible to redefine the format by using 'pattern' attribute. Examples of the elements with type 'xdt:date' are here:

<Date1 type="xdt:date"> 2002/12/31 </Date1>
<Date2 type="xdt:date" pattern="DD-MM-YYYY"> 31-12-2002 </Date2>
<Date3 type="xdt:date" pattern="MM/DD/YYYY"> 12/31/2002 </Date3>
<Date4 type="xdt:date" pattern="MM/YY"> 12/02 </Date4>

First example uses default format of data with type 'xdt:date'. Second and third examples show just different formats specifying accepted dates. In the last example a year should be represented by two lower digits.

In the case when it is required to use a long date format (instead of short date format as it is shown above) it is recommended to use key reserved words "Month" and 'Day-of-the-week' (upper or lower case of the first character in these key words defines usage of upper or lower case in actual data instance).

<Date5 type="xdt:date" pattern="Day-of-the-week, Month DD, YYYY">
  Wednesday, March 07, 2001 </Date5>
<Date6 type="xdt:date" pattern="day-of-the-week, DD de month de YYYY">
  miércoles, 07 de marzo de 2001 </Date6>

These two examples show usage of the format string for long date format in English (US), and Spanish (Spain).

Attribute 'limits' may be used to enumerate a finite set of all possible data values, or put additional restrictions on the data values. Format of permitted values should comply to the format specified by attribute 'xdt:date', or if it is omitted - to the default date format.
An example of usage of attribute 'limits' is here:

<DateWithLimits type="xdt:date" limits="2002/05/03|2002/05/04|2002/05/05">
  2002/05/04
</DateWithLimits>

Be noticed, that in the case, if attribute 'limits' must be used, to avid possible ambiguity do not use symbol '|' in format string (default format does not contain this symbol).

All examples above require to use two (or four) digits per each subfield (YYYY/MM/DD). It means that data instance should exactly have two (or four) digits value like this 1954/01/02 (with adding zeroes in front). To allow short format in data instances specify it in 'pattern' string with just one corresponding character. In this case if real data has more then one digit - it uses all of them.
An example below allow the short format, where creator of data instance has not been required to use four digits in "year" subfield (while at least two digits must be present), as well as two digits in "month" and "day" subfields respectively.

<ShortDate type="xdt:date" pattern="YY:M:D"> 54/1/2 </ShortTime>

6.6. time

An element with type 'xdt:time' can be any time-formatted string.

List of attributes modifying this type:
limits, pattern, occur

Default format string is "hh:mm:ssGMT". Where:
hh - hours (0 - 23),
mm - minutes (0 - 59),
ss - seconds (0 - 59),
GMT - keyword (Greenwich Mean Time) which in a data instance should be replaced with UTC (Coordinated Universal Time), as the base followed by a positive or negative number indicating the offset for the time zone in hours and minutes.
Examples of data instances containing time type values are below:

<Time1 type="xdt:time">
  15:25:30-8:00
</Time1>
<Time2 type="xdt:time">
  03:10:55+3:00
</Time2>

By default format uses 24-hour clock presentation. In the case if there is need to use 12-hour AM/PM model (used in the United States) it is possible to put keyword 'HDTM' (half-day time model) after the time format in pattern string. Be noticed that 'hh' value is restricted to 1 - 12 range. Example is below.

<Time3 type="xdt:time" pattern="hh:mm:ss HDTM GMT">
  03:25:30 PM -8:00
</Time3>

Compare this example with value for "Time1" in example above. "Time3" has exactly the same time.

It is possible to redefine the time format by using 'pattern' and put additional restrictions by applying 'limits' attributes. Here are examples:

<xdt:define new-type="tAtWork" type="xdt:time"
  pattern="hh:mm" limits="8:00-17:00|{13:00-14:00}"/>
  another valid type definition:
<xdt:define new-type="tNewTimeFormat" type="xdt:time"
  pattern="hh-mm-ss.ppp"/>

Content of an element with type "tAtWork" has to be formatted accordingly to the provided pattern and is limited to specified timeframe. A valid example of data instance is below:

<CallMe type="AtWork"> 15:00 </CallMe>

An example of the instance of data with type "tNewTimeFormat" is below. It uses 'ppp' following by dot sign '.' indicating parts of a second. Number of 'p' specifies required precision.

<StartTime type="tNewTimeFormat"> 17-15-30.452 </StartTime>

All examples above require to use two digits per each subfield (hh:mm:ss). It means that data instance should exactly have two digits value like this 01:02:03 (with adding zeroes in front). To allow short f