[Up] |
Work in progressThis version may be updated without notice. |
Copyright © INRIA
and often refer to types of values. Any library of types of values may be used, and new types libraries may be defined. For example, a module often defines new types for its own needs, and users may also define their own types of values.
This document describes the types of values introduced in the
specifications. It also describes how to use W3C XML Schema types and XML types in in general and particularly, with semantic preservation. The types described here are only built-in types ; additional built-in types may be described in other specifications ; non built-in (user defined) types can be defined thanks to .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Note that for reasons of style, these words are not capitalized in this document.
The following specifications are part of the technologies.
1.1 Types in2 Typed datas in
1.2 Types in
2.1 Types of value references3 Reference
2.2 Typed datas
2.3 Types functions
3.1 Built-in types3.1.1 W3C types3.2 Functions
3.1.2 Active Tags Datatypes
An XML-aware type is a type that is relevant regarding to XML datas.
Such a type is a high level abstraction of a class of raw data. A raw data can be with or without XML structure. An XML-unstructured raw data is a text value, or a part of a text value, that appears in text contents or attribute values ; on the opposite, an XML-structured raw data is an XML tree, or a part of an XML tree.
Of course, many types are composite types, that is to say composed with other types. Additionally, programs can construct directly typed datas without the help of XML.
As examples of XML-structured datas, an XML Catalog is an XML document that can be unmarshalled to a "catalog object" ; an XSLT Stylesheet is an XML document that can be unmarshalled to a "stylesheet object"...
As examples of XML-unstructured datas, "12345" is a raw text that can be parsed to an integer object ; "10 juin 1969" is a raw text that can be parsed to a date object...
technologies deal with both XML-structured and XML-unstructured raw datas, but most of the structured datas used are whole XML trees.
The types mentionned in the
specifications are called s.An
is simply an identifier that denotes which kind of object is expected to proceed to a particular operation. One distinguishes 2 families of types :Marker types are neutral regarding the implementation of an XML qualified names used to identify object classes.
engine. Marker types are justSome objects handled by an cross-operable objects, implementations are free to deal with their type name as expected in the relevant specification or with the implementation-dependant class-name of the object, as shown in the type() function.
engine are not necessarily XML-aware but may be referenced by their types of values in any specifications and applications. In this case, the types stand just as markers on this kinds of objects that implementations can refer to in the aim of handling the right object when necessary. As such objects are not necessarilyA cross-operable object is not an XML object such as an XML element but behaves as if it was ; a cross-operable object may be built or not from an XML data source. Thus, the type of a cross-operable object may be a marker type (like io:x-file) or an XML-aware type (like cat:catalog) ; Notice that many XML-aware type can be built from non-XML data sources, according to the implementation ; this is the case of cat:catalog instances that could be built from legacy plain-text catalog formats.
A typed data is usually an object of an XML-aware type, more often an XML-unstructured data. Some implementation may provide typed datas that correspond to marker types.
The local name of complex ·cross operable objects· are usually prefixed with x-, like exp:x-dataset and unlike exp:module.
In , data types are identified with qualified names, but they can also be unnamed.
Types of unstructured values are used to define constraints on textual values inside an XML document, that is to say :
ASL provide means to define easily custom types.
The types that can be defined with an
are very different to marker types : the former are defined for XML documents (that can be an ), the latter are defined for actions exclusively.The notion of marker type is understandable exclusively in the context of adt:expression at best.
, when an is running. Thus, module definitions must refer to the concrete object that a specific action can handle. Within module specifications, the objects handled at runtime must be specified, for example in attribute values. If such object is a marker type, the associated schema can specify anFor example, let's define an I/O input stream ; the type of such object is the marker type io:input. Let's define the <io:read> element action, that have the @input attribute. The I/O module in one hand specifies that this attribute must be a runtime object of the type io:input. The associated schema on the other hand indicates that the @input attribute of the <io:read> element is of the type adt:expression.
A type of value expected to proceed to a particular operation may be:
Many XML-aware types can be expressed with hard-coded values : "12345" can stand for an integer, and "10 juin 1969" for a date. Typed datas that are more complex objects can't be expressed with hard-coded values ; they appear in an expressions :
inside<xcl:transform name="html" output-type="DOM" source="{$xml}" stylesheet="{$xmlToHtml}"/>
The source and the stylesheet expected in the <xcl:transform> element are returning a reference to the relevant object. Notice that an extended expression could also be used, like this : {$myStylesheets/xmlToHtml} ; this is also valid if a stylesheet object is returned by this expression.
Objects that can't be hard-coded values are pure runtime values ; it is an inherent characteristic of their type. The expression is required. Additionally, if not specified, an operation that requires a value that can be hard-coded must raise an error while unmarshalling if an expression is provided instead of a hard-coded value.
specifications and applications can mention that an operation that requires a pure runtime value may safely expose its data type without mentionning that anFor example, the @output-type attribute used above accept xs:string values ; attempting to provide an expression will raise an error when unmarshalling. On the opposite, the @source attribute requires xml:node values ; such values must be provided thanks to an expression, because the xml:node type is a marker type.
A typed data is a cross-operable object that wraps an object, its value : the object can be retrieved with the value() function. The object can also be retrieved in the content of the typed data. The "typed object" type is like a marker type that has no name : the type() function applied on a typed data returns the type name of the wrapped object ; if the object has an anonymous type, the null value is returned.
Additionally, a typed data has a set of characteristics exposed as attributes, and known as facets in W3C XML Schema.
[TODO: examples]
Moreover, compatible typed datas are comparable within XPath expressions ; for example :
<xcl:set name="cold" value="{my:temperature('0°C')}"/> <xcl:set name="colder" value="{my:temperature('31°F')}"/> <xcl:if test="{ $colder < $cold }"> <xcl:then> ... </xcl:then> </xcl:if>
...assuming that the type of the datas returned by the my:temperature() function would process temperature scales correctly, then the test above is true.
The specification provides an example of an implementation of this type.
Most types have a counterpart function that allows to create a typed data of this type.
In the example above, both the my:temperature type and the my:temperature() function are available. The former is used to refer to datas of this type, the latter to produce such a data at runtime. Notice that the counterpart function is not necessary the sole mechanism that allow to produce a data of this type : many active tags are often use to produce a property, which value is a typed data.
Neither this specification nor the
specification are intending to provide a way to bind a counterpart function to a type.This task is dedicated to EXP which provides means to define counterpart functions. EXP also allows to define XPath functions as macro functions, as shown in this example.
This chapter defines the data types and counterpart functions proper to
, and borrows to other well-known XML specifications some names that are understandable as indicated above exclusively in the scope of the specifications and applications.Allows a read operation. | |
Allows a write operation. | |
Allows a rename operation. | |
Allows an update operation. | |
Allows a delete operation. |
This chapter is a bridge between the notion of type used in the
specifications, and types provided by the W3C. The W3C types are those clearly defined in the W3C XML Schema specifications, and those unformally borrowed from XML and arranged in this specification for specifications and applications.This specification defines XML types for information items found in XML documents. This types are endorsing the natural prefix xml used for XML purposes. The meaning of this types are limited to the
specifications and applications.The following types are bound to the xml namespace URI : http://www.w3.org/XML/1998/namespace
An XML document
An XML node
An XML element
An XML attribute
An XML processing instruction
An XML comment
An XML text
An XML namespace declaration
An XML error.
Operation read | write | rename | update | delete Type Value Comment type() xs:QName xml:x-error This type name() The type of error. xs:string warning A warning, as specified in the XML recommendation. error A recoverable error, as specified in the XML recommendation. fatal-error A non-recoverable error, as specified in the XML recommendation. string() xs:string The message of the error. parent:: error cause The implementation dependant error that cause this error, if any. attribute:: A set of attributes including those specified below (and that can't be removed). Additional attributes may be set, removed or updated, if they are not bound to a namespace URI. @line-number xs:int The line number of the end of the text where the error occurred. @column-number xs:int The column number of the end of the text where the error occurred. @public-id adt:public-id The public identifier of the entity where the error occurred. @system-id xs:anyURI The system identifier of the entity where the error occurred.
W3C XML Schema provides a library of common types. This specification provides an adaptation of these types for
. Notice that the original semantic of each type is preserved according to the W3C XML Schema specification.The following types are bound to the WXS namespace URI : http://www.w3.org/XML/2001/XMLSchema
A boolean
An int
Extends adt:QNameSet .A QName
[TODO: all WXS types and counterpart functions]A string
Other marker types are like XML types mentionned above. The meaning of this types are limited to the
specifications and applications.The xsl prefix is bound to http://www.w3.org/1999/XSL/Transform
A stylesheet object.
The following types are bound to the namespace URI : http://www.inria.fr/xml/active-datatypes
A list of separated with blanks.
A prefix is an xs:NCName involved in a namespace declaration inside which it is in scope.
A list (separated with blanks) of adt:prefixes involved in a namespace declaration inside which it is in scope.
An expression is a mixed string of simple strings and XPath expressions surrounded by curly braces. Simple strings are strings that doesn't contain curly braces, or that escapes { and } with {{ and }}.
An expression is an XPath expression surrounded by curly braces.
An XPath expression.
Extends adt:QNameSet .A pattern that matches paths to nodes.
A named item is an object with a name. The name is a xs:QName.
A list of objects.
Extends adt:list .A component behaves like an XML element, except that its attributes values are not necessarily a string, and its content is not necessarily composed of nodes. Any object may be used instead.
xml:attributes and adt:NItem that are appended to this list are set like attributes to this list.
A set of objects. A set is like a list inside which each object is unique.
A set of objects bound to a key.
An XML public identifier.
A string made of xs:QNames with their namespace URI bindings. The canonical path of a node is of this type.
A adt:QNamesSet can be normalized in order to disambiguish several overlapped mappings (same prefix with several namespace URIs in the set). A adt:QNamesSet is normalized automatically when a set of xs:QNames have to be inserted as a value (attribute value or text) inside an XML tree : to be consistent, the namespace URIs defined in the adt:QNamesSet must be defined in the host document, but existing mappings must be preserved.
As such value might have to be normalized if it has to be inserted, say, as an attribute value, the host element should then define the expected namespace bindings when necessary, which might cause some prefixes used in this value to be renamed.
By definition, a xs:QName is a adt:QNameSet with a single item.
Create an empty list.
Create an empty component.
Create an empty map.
Create an empty set.