XML Schema 1.1 implementation

The xs:override declaration is implemented. Pending resolution of specification bug 9661, a declaration that appears within xs:override and does not override anything in the overridden schema is included in the schema; the other possible interpretation of the specification is that it should be ignored. Restrictions: circular xs:override chains are not allowed, and there has been no testing of the interaction of xs:override with xs:redefine.

Saxon recognizes the attribute saxon:extensions on the xs:schema element: the value is a space-separated list of strings giving the names of extensions that are enabled in this schema document. If the extension id-xpath-syntax is enabled, then the XPath syntax permitted in the xs:selector and xs:field elements of uniqueness, key and keyref constraints is extended to allow any streaming pattern. For example, this allows the use of attribute-based predicates, such as xpath="employee[@location='us']"

The new primitive type xs:precisionDecimal is implemented - at least, to the extent required for schema validation. It is not recommended yet to use this type in documents subject to query and transformation, or to use it for free-standing atomic values, since (a) there is no specification for how operations such as arithmetic and comparison should behave in XPath, (b) there are gaps in the implementation in this area, (c) very limited testing has been done, and (d) the type could yet be dropped (it is marked as a "feature at risk", and there is some political objection to it).

Inheritable attributes are implemented (for use in Conditional Type Assignment only: the only effect of declaring an attribute to be inheritable is that it can be referenced in the XPath condition of the xs:alternative element).

An element may now have more than one ID attribute. Several ID attributes or children of an element may have the same value. ID and IDREF values appearing within a list, or as a member type of a union, are now recognized. (Most of these changes have been applied also to XSD 1.0, with the exception that multiple ID attributes are not allowed on an element. Saxon 9.2 and earlier releases correctly allowed an element to have more than one ID-valued child element, but incorrectly reported an error if more than one ID-valued child of the same parent element had the same ID value. The rules for list types and union types with an ID or IDREF member are unclear in XSD 1.0, so for simplicity, the XSD 1.1 rules have been implemented unconditionally.

It is now an error for the outermost element of the document (the validation root) to be of type xs:ID. (The rules in the W3C spec have always implied this, though many cases in the W3C test suite consider this to be valid. The Working Group has confirmed in its decision on bug #9922 that this is intended to be invalid.)

In element wildcards, notQName="##definedSibling" is implemented.

An xs:all group may now contain an xs:group element to refer to a named model group declaration, provided the named model group definition in turn contains an xs:all group, and that minOccurs = maxOccurs = 1.

The way that xs:anyURI values are checked (to see if they are valid URIs) has changed. In accordance with the W3C specifications, there is now no checking at all when XSD 1.1 is selected at the Configuration level - any string may be used. When 1.0 is selected, strings are checked to be valid URIs (as defined by the java.net.URI class) only when performing schema validation, or explicit casting from string to xs:anyURI. There is no longer any check performed by methods such as namespace-uri() or namespace-uri-from-QName, regardless whether XSD 1.0 or XSD 1.1 is selected in the Configuration. It is also possible to configure the checking that is performed to use a user-supplied URIChecker, for example one that performs stricter or more liberal checking.