Importing Schemas

The facilities that we've been discussing in this chapter work only if schema information is available to the XSLT processor. The primary way that the processor gets this information is through the <xsl:import-schema> declaration, which can be used at the top level of any stylesheet module.

The <xsl: import-schema> declaration is modeled on the <xs: import> element within the XML Schema specification, but with some concessions to the XSLT house style (for example, the schemaLocation attribute in <xs: import> becomes schema-location in XSLT). Importantly, it adopts the same deliberate vagueness about exactly where the schema comes from, giving implementations the freedom to implement local schema caches or catalogs.

The most important attribute is the namespace attribute. This gives the target namespace of the schema being imported. If the attribute is omitted, this represents a request for a schema with no target namespace. You can only import one schema for any given namespace, plus one for the null namespace. This can create a problem if both your source document and your result document are defined by schemas with no target namespace: You won't be able to import both schemas. You can use the <xs:redef ine> mechanism in XML Schema to map one of them (say the result schema) into a namespace, but you will then have to generate the result elements in this namespace, and perhaps apply a second transformation subsequently to get rid of the unwanted namespace.

You should import each schema that contains a type definition, element declaration, or attribute declaration that your stylesheet refers to by name . Importing a schema that in turn imports another schema isn't good enough: The only names that become available for use in your stylesheet are those defined in the schemas for the namespaces that you import explicitly. The XSLT processor is given some leeway to implicitly import schemas that aren't requested explicitly in the stylesheet. This is intended particularly for use in highly controlled environments, such as running a transformation within an XML database engine where the available schemas are all known in advance. But it's unwise to rely on this if you want your stylesheet to be portable.

The schema-location attribute of <xsl: import-schema> defines a URI where the schema can be located. This is described in the specification as a hint, which means that if the XSLT processor knows a better place to look, it is free to do so. For example, it might already have a precompiled copy of the schema held in memory. If you don't supply a schema-location attribute, then the schema import will work only if the XSLT processor already knows where to look. It's possible, for example, that some XSLT processors might have built-in knowledge of common schemas such as the XHTML schema, so they never need to fetch the XML source. However, if you want your stylesheet to be portable, it's probably a good idea to specify the schema location.

You don't need to import schemas into every stylesheet module individually. Importing a schema into one stylesheet module makes its definitions available in all stylesheet modules. (This is a notable difference from the equivalent facility in XQuery.)

What happens if you have two <xsl: import-schema> declarations for the same namespace URI (or, more probably, for the null namespace)? This can easily happen when different stylesheet modules are combined into a single stylesheet. Firstly, the system chooses the one with the highest import precedence, as explained in Chapter 3. If this leaves more than one, then they are all used. The XSLT specification explains how conflicts are resolved by reference to the XML Schema specification: It's defined to be the same as if you have two <xs:import> declarations for the same namespace in a schema. This is rather passing the buck, as it happens, because XML Schema leaves a lot of latitude to implementations in deciding how far they will go in analyzing two different schemas for conflicts. It's best not to do it. Since the processor is perfectly entitled to ignore the schema-location hint, it is also entitled to assume that if it already has a schema for a given namespace loaded, then this is the one that the user wanted.

As with validation, the XSLT specification describes the semantics of schema import by means of a rather artificial device: It defines the effect by reference to a synthetic schema document that is assembled to contain <xs: import> declarations representing each of the <xsl: import-schema> declarations in the stylesheet. The reason for this artifice is that it provides a way of invoking the rules of XML Schema and saying that they apply equally to XSLT, without actually copying the rules and repeating them, which would inevitably lead to inconsistencies. No real implementation is likely to integrate the XSLT processor and the schema processor in the clumsy manner described in the spec.

You don't need to import a schema merely because it is used to validate source documents. However, I would recommend doing so. If you don't, this creates the possibility that a source document will contain type annotations that mean nothing to the XSLT processor. There are various ways an XSLT processor can deal with this problem (no less than four possible approaches are described in the specification, one of which is to raise an error) but the simplest approach is to avoid the problem by ensuring that all the schemas used in your transformation are explicitly imported.