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 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.
