XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (246 page)

It is necessary to designate a namespace as an extension element namespace only to distinguish extension instructions from literal result elements. At the top level of the stylesheet, there is no risk of confusion. Any implementation can define its own top-level elements, using its own namespace, and other implementations will simply ignore these elements, treating them as data. So the
extension-element-prefixes
attribute is not needed to identify top-level elements used as vendor or user extensions. For example, you can use

as a top-level declaration, and processors other than Microsoft MSXML will probably ignore it (though there is nothing that says they have to).

Usage

This attribute should be set to a list of all the prefixes you are using for extension instructions in your stylesheet. The most common cases are either to omit it entirely or to include a single prefix for the namespace used by the vendor of your chosen XSLT processor for their own proprietary extensions. There will always be a namespace declaration for this namespace on the

element as well.

For example, if you are using Saxon:

Don't include the vendor's prefix unless you are actually using their proprietary extensions in the stylesheet. You don't need to include this attribute to use proprietary top-level elements such as

, or to use extension functions: You need it only if you want to use vendor-defined instructions within a sequence constructor, where they would otherwise be assumed to be literal result elements. An example of such an instruction in Saxon is

, which allows you to generate a DTD for the result document.

If your usage of vendor extensions is highly localized within the stylesheet, it is better to identify them using the
xsl:extension-element-prefixes
attribute of the extension element itself, or of a literal result element that surrounds the sequence constructor where the extensions are actually used. This aids portability and makes it easier to see which parts of the stylesheet are standard and which parts use proprietary extensions.

If you want to use extensions supplied by several different vendors, you can list them all in this attribute. An XSLT processor from one vendor won't object to finding another vendor's namespace in the list; it will only object if it is actually asked to evaluate a proprietary instruction that it doesn't understand, and even then if there is an

child element that defines the fallback behavior, it will carry on calmly executing that in place of the unrecognized instruction.

Although extension elements supplied by XSLT product vendors are likely to be the most common case, it's also possible in principle to install third-party extensions or to write your own (however, the APIs for doing so will be different for each vendor). So everything we've said about the vendor's extensions applies equally to your own extensions and those acquired from a third party.

For more information about the extensions provided by various vendors in their products, see the documentation for the relevant product.

An inventive way of using the
extension-element-prefixes
attribute is to flag elements that you want to reserve for debugging or annotation. For example, if you include the following element within a sequence constructor anywhere in the stylesheet, then the normal action will be to output an element to the result tree, showing the current values of the variables
$var1
and
$var2
.

When you no longer need to use this debugging instruction, you can disable it simply by declaring
debug
as an extension element prefix. This time the

action will be taken, because the processor doesn't recognize the extension instruction.

The input-type-annotations Attribute

This attribute allows a processor to specify that it wants to treat input documents as untyped even if they have been schema-validated.

Effect

Specifying
input-type-annotations=“strip”
causes all type annotations on input documents to be removed before any further processing. The term
input documents
here means the principal input document and any documents read using the functions
doc()
,
document()
, or
collection()
. The effect of stripping type annotations is that elements become marked as
xs:untyped
, and attributes as
xs:untypedAtomic
. The
nilled
flag on every element is set to false, but the flags that mark a node as an ID or IDREF are unaffected.

Unlike the other attributes,
input-type-annotations
does affect included and imported modules. The reason for the difference is that it takes effect at runtime, not at compile time. The rule is that if any module specifies
strip
, then annotations will be stripped, unless there is also a module that specifies
preserve
in which case an error is reported. The value
unspecified
means what it says: it's the same as not including the attribute at all.