XML Schema 1.1 Conformance

Saxon includes a complete implementation of the proposed specification of XSD 1.1. At the time of release of Saxon 9.4, the specification is very close to becoming a Recommendation, and there is a test suite that is believed to cover all new features of the specification. Saxon achieves 100% pass rate againts these tests. Saxonica has worked closely with other implementors of XSD 1.1 to ensure that implementations are fully interoperable. There is still, however, a possibility that the treatment of some edge cases in the specification will change, or that new tests will be added which Saxon does not pass.

XSD 1.1 features are available only if explicitly requested by using the -xsdversion:1.1 option on the command line, or equivalent options in the API.

The rules for valid type derivation follow the XML Schema 1.1 specification, regardless of this option setting. This is because the rules in the 1.0 specification do not meet the stated intent, namely that type derivation is valid in all cases where the restricted type allows a subset of the instances permitted by the base type.

An outline of the changes between XSD 1.0 and XSD 1.1 can be found in Appendix G of the specification.

Implementation-defined features

Appendix E1 of XSD 1.1 (Part 1) provides a checklist of implementation-defined and implementation-dependent features. The following list describes how these are implemented in Saxon.

• For the datatypes defined by [XML Schema: Datatypes] which depend on [XML 1.1] or [XML Namespaces 1.1], it is ·implementation-defined· whether a schema processor takes the relevant definitions from [XML 1.1] and [XML Namespaces 1.1], or from [XML 1.0] and [Namespaces in XML 1.0]. Implementations may support either the ·XML-1.0-based· datatypes, or the ·XML-1.1-based· datatypes, or both. The same applies to the definition of whitespace.

  The definition of whitespace is the same in all XML editions. The definition of the syntax of names is the same in XML 1.1 and in XML 1.0 fifth edition, and Saxon uses this definition

• It is ·implementation-defined· whether a schema processor can read schema documents in the form of XML documents.

  Saxon-EE can read XML schema documents.

• Whether a processor is able to retrieve schema documents from the Web is ·implementation-defined·. (See Conformance (§2.4), which defines "·Web-aware·" processors as processors which can retrieve schema documents from the Web.)

  Saxon-EE is able to read XML schema documents from the Web.

• The way in which a processor is invoked, and the way in which values are specified for the schema to be used, the information item to be validated, and the declaration or definition with which to begin validation, is ·implementation-defined·.

  Saxon-EE allows validation to be invoked from the command line, via a Java or .NET API, or from XSLT and XQuery. The documentation fors interfaces provides the required information.

• The manner in which a processor provides access to the information items and properties in the PSVI to any downstream or user applications, or to the invoker, is ·implementation-defined·.

  Saxon provides only that part of the PSVI used by the XQuery and XSLT specifications. This amounts to adding a type annotation to each element and attribute node where the outcome of validation is 'valid', and providing error messages where it is not.

• The information items and properties in the PSVI to which the processor provides access, if any, is ·implementation-defined·.

  See previous answer.

• When the ·post-schema-validation infoset· includes [type definition name] and similar properties, it is ·implementation-defined· whether unique names are provided for anonymous type definitions.

  Saxon allocates unique names to anonymous type definitions.

• The method used for assembling a set of schema components for use in validation is ·implementation-defined·.

  Saxon generally assembles schema components from XML schema documents as described in the XSD specification. However, it has built-in knowledge of the schema for the XML namespace, and these components can be included in a schema simply by importing the relevant namespace. It also has built-in knowledge of the schema components defined in the FN namespace, used in the result document of the analyze-string function in XPath 3.0

• It is ·implementation-defined· whether a schema processor provides a value for the [type definition name] and [member type definition name] properties of attribute and element information-items. If it does so, the choice of name is ·implementation-dependent·.

  The information is not directly available.

• Everything ·implementation-defined· in [XML Schema: Datatypes] is also ·implementation-defined· in this specification. Note: This includes, but is not limited to, the choice of ·XML-1.0-based· or ·XML-1.1-based· datatypes, or both; support for ·implementation-defined· primitive datatypes; and support for ·implementation-defined· constraining facets. See the appendix on implementation-defined and implementation-dependent features in [XML Schema: Datatypes].

  See the checklist that follows.

• It is ·implementation-defined· whether a processor detects violations of clause 2.4.2 of Derivation Valid (Restriction, Complex) (§3.4.6.3) (a) always by examination of the schema in isolation, (b) only when some element information item in the input document is valid against its ·governing type definition· T but not against T.{base type definition}, or (c) sometimes the one and sometimes the other. In case (c), the circumstances in which the processor does one or the other are ·implementation-dependent·.

  Saxon-EE attempts to detect all violations of Derivation Valid by examination of the schema in isolation; if it is not able to determine at this stage that the derivation is valid, the schema is considered to be in error.

• It is ·implementation-defined· when a processor detects type errors in XPath expressions and whether it treats type errors as static or dynamic errors.

  Saxon uses optimistic static type checking; it reports a static error in the XPath expression if its type analysis concludes that the type of a supplied value and the type required by the context in which it is used are disjoint, so that execution can never succeed.

• It is ·implementation-defined· under what conditions a processor will detect the equivalence of two distinct Type Table or Type Alternative components. All processors must detect equivalence under certain specified conditions, but the ability to detect equivalence under other conditions is not constrained.

  In considering whether two type tables are equivalent, Saxon tests the equivalence of XPath expressions by comparing their normalized expression trees. Inessential factors such as whitespace and parentheses are therefore ignored, and in some cases different expressions are recognized as equivalent, for example (a=b) is equivalent to (b=a). In general the two expressions must have the same static context, but differences in the static context that do not affect the outcome of evaluating the expressions may be discounted.

• It is ·implementation-defined· what effect invalid elements within <annotation> have on the construction of schema components from a schema document, and whether a processor treats schema documents which are invalid only in consequence of containing such invalid elements as being in ·error· or not.

  Saxon ignores the content of annotations entirely, other than ensuring that they are namespace-well-formed.

A similar checklist appears in appendix H.1 of XSD 1.1 Part 2. The corresponding answers for Saxon-EE are given below.

• For the datatypes which depend on [XML] or [Namespaces in XML], it is ·implementation-defined· whether a conforming processor takes the relevant definitions from [XML] and [Namespaces in XML], or from [XML 1.0] and [Namespaces in XML 1.0]. Implementations may support either the form of these datatypes based on version 1.0 of those specifications, or the form based on version 1.1, or both.

  See above. The definitions are taken from XML 1.0 Fifth Edition and XML 1.1, which are identical.

• For the datatypes with infinite ·value spaces·, it is ·implementation-defined· whether conforming processors set a limit on the size of the values supported. If such limits are set, they must be documented, and the limits must be equal to, or exceed, the minimal limits specified in Partial Implementation of Infinite Datatypes (§5.4). .

  For integers, decimals, and strings, the only limits imposed by Saxon are those inherent in the underlying Java types BigInteger, BigDecimal, and String.

  For calendar data types, the year must be in the range of a signed 32-bit integer.

  For durations, the number of months must fit in a signed 32-bit integer; the integer number of seconds must fit in a signed 64-bit integer, and the precision is to microseconds.

• It is ·implementation-defined· whether ·primitive· datatypes other than those defined in this specification are supported.

  Saxon does not support any additional primitive datatypes.

• It is ·implementation-defined· whether ·constraining facets· other than those defined in this specification are supported.

  Saxon supports an additional facet, saxon:preprocess. This is a pre-lexical facet that invokes user-written Java code to modify a value before validation and before serialization. For example, this can be used to allow xs:decimal values to be written using comma as a decimal point. For details see The saxon:preprocess facet.