XML Schema

XML Schema 1.0

The implementation of xs:redefine has been revised slightly, to better reflect the notion of "pervasiveness" described (with tantalising lack of detail) in the language specification. Every component now has a redefinition level; a component defined within xs:redefine has a redefinition level one higher than that of the component it redefines. If two different but identically-named components have the same redefinition level, this is an error; but if they have different redefinition levels, the higher one wins. An example where this comes into play is if a module R.XSD contains two xs:redefine elements; the first one redefines A.XSD, which itself includes B.XSD, and the second redefines B.XSD, providing a revised version of a type T contained in B.XSD. Previously Saxon reported this as an error, on the grounds that the schema returned by the first xs:redefine and the schema returned by the second xs:redefine could not be combined because they contained incompatible definitions of type T. This schema is now accepted as valid, and the redefined type T wins.

In the command line interface, a new option -config:filename is available. This refers to a configuration file in which many configuration options can be specified. The configuration described by this file must be an EnterpriseConfiguration. Options specified directly on the command line override corresponding options in the configuration file. The format of the configuration file is given in The Saxon configuration file.

The bogus gMonth format --MM-- is no longer accepted. This format appeared in error in the original XML Schema 1.0 Recommendation, and was subsequently corrected by erratum. It still appears in a number of books on XML Schema. It was recognized in all Saxon releases until and including 9.1. The correct format is --MM.

XML Schema 1.1

The type xs:error has been implemented.

The facility for conditional inclusion of parts of schema documents, based on attributes such as vc:minVersion and vc:maxVersion, is now implemented. This works whether the schema processor is in 1.0 or 1.1 mode, allowing a schema that is processed in 1.0 mode to ignore facilities such as assertions that require XSD 1.1.

For this purpose the set of types that are "automatically known" to the processor includes only the built-in types (which are currently the same for XSD 1.0 and XSD 1.1, with the exception of xs:error which is available only in 1.1), and the set of facets are the built-in facets, which includes xs:assert when running in 1.1 mode, but not when running in 1.0 mode.

An element declaration may now appear in more than one substitution group.

The ref attribute of xs:unique, xs:key, and xs:keyref has been implemented.

The notNamespace and notQName attributes are now supported on xs:any and xs:anyAttribute wildcards. However, the option notQName="##definedSibling" is not yet implemented.

Although these attributes are only available when XSD 1.1 is enabled (command line switch -xsdversion:1.1), a side-effect of the change is that wildcard unions and intersections that were not expressible in 1.0 are now expressible, and this change applies whether or not 1.1 is enabled. This means that some rather obscure conditions that are errors in 1.0 but not in 1.1 are no longer detected as errors.

The algorithm for testing subsumption among xs:all content models now performs a more intelligent analysis of wildcard particles.

Open content is implemented. The xs:defaultOpenContent element can appear as a child of xs:schema, and and xs:openContent as a child of xs:complexType, xs:extension or xs:restriction. This works with sequence, all, empty and mixed content models.

There are some limitations in subsumption testing: for a type R to be a valid restriction of B, the "primary content" of R must be a valid restriction of the primary content of B, and the "open content" of R must be a valid restriction of the open content of B.

Default attributes are implemented (that is, the defaultAttributes attribute of xs:schema, and the defaultAttributesApply attribute of xs:complexType).

An xs:all content model may now be derived by extension from another xs:all content model.

A new facet xs:explicitTimezone is available with values required, optional, or prohibited. This allows control of whether or not the timezone part of a date, time, dateTime, gYear, gYearMonth, gMonth, gMonthDay, or gDay is present or absent.

The new built-in data type xs:dateTimeStamp (an xs:dateTime with timezone required) is implemented.

Saxon XSD Extensions

In assertions, and on all elements representing facets (for example pattern), Saxon supports the attribute saxon:message="message text". This message text is used in error messages when the assertion or facet is not satisfied.

The XSD 1.1 specification allows vendor extensions in the form of vendor-defined primitive types and vendor-defined facets. Saxon 9.2 exploits this freedom to provide a new facet, saxon:preprocess. This is a pre-lexical facet (like xs:whiteSpace) in that it is used to transform the supplied value before validation. The preprocessing is done using an arbitrary XPath expression which takes a string as input and produces a string as output. For example <saxon:preprocess action="normalize-unicode($value)"/> can be used to perform Unicode normalization, while <saxon:preprocess action="upper-case($value)"/> normalizes the value to upper case. This is done before application of other facets such as the pattern and enumeration facets. It is also possible to provide another XPath expression to reverse the process, for use when the typed value is converted back to a string. For more information see The saxon:preprocess facet.