XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (77 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
1.
The result tree must be a well-formed document: That is, it must contain exactly one element node, and no text nodes, among the children of the document node. (In the absence of validation, this rule can be relaxed. For example, it is possible to have a temporary tree in which the document node has three element nodes as its children.)
2.
The document element (that is, the single element node child of the document node) must validate against the schema definition of the specified type, according to the rules defined in XML Schema.
3.
The document must satisfy document-level integrity constraints defined in the schema. This means:
- Elements and attributes of type
xs:ID
must have unique values within the document. - Elements and attributes of type
xs:IDREF
or
xs:IDREFS
must contain valid references to
xs:ID
values within the document. - Any constraints defined by
Document-level validation rules must also be satisfied when validation is requested using the option
validate = “strict”
orvalidate = “lax”.
The language of the XSLT specification that describes these rules is somewhat tortuous. This is because XSLT tries to define what validation means in terms of the rules in the XML Schema specification, which means that there is a need to establish a precise correspondence between the terminologies of the two specifications. This is made more difficult by the fact that XML Schema is not defined in terms of the XSLT/XPath data model, but rather in terms of the XML Infoset and the Post Schema Validation Infoset (PSVI), which is defined in the XML Schema specification itself. To make this work, the XSLT specification says that when a document is validated, it is first serialized, and then re-parsed to create an Infoset. The Infoset is then validated, as defined in XML Schema, to create a PSVI. Finally, this PSVI is converted to a document in the XPath data model using rules defined in the XDM specification. However, you should regard this description of the process as a purely formal device to ensure that no ambiguities are introduced between the different specifications. In practice, an XSLT processor is likely to have a fairly intimate interface with a schema processor, and both are likely to share the same internal data structures.
If you request validation by specifyingvalidation = “strict”orvalidation = “lax”, this raises the question of where the XSLT processor should look to find a schema that contains a suitable element declaration. The specification leaves this slightly open. The first place a processor will look is among the schemas that were imported into the stylesheet using
Importing Schemas
on page 180. The processor is also allowed (but not required) to use any
xsi:schemaLocation
or
xsi:noNamespaceSchemaLocation
attributes that are present in the result document itself as hints indicating where to locate a suitable schema. My advice, however, would be to make sure that the required schemas are explicitly imported.
Validating a Temporary Document
In the previous two sections, we have seen how you can validate a source document that is to be processed by the stylesheet, and how you can validate result documents produced as output by the stylesheet. It's also possible to apply validation to temporary documents created and used internally during the course of stylesheet processing.
The most common way to create a temporary document is by usingasattribute, for example:
The value of this variable will be the document node at the root of a newly constructed temporary tree. The body of the tree in this case is produced by the
The example above can be regarded as shorthand for the more detailed construction:
