What Vendor Extensions are Allowed?


The XSLT 2.0 language specification makes no distinction between what vendors are allowed to do, and what users and third parties are allowed to do. For example, it says that the set of languages supported by the format-date () function is implementation defined. This can be interpreted in two ways:

  • Vendors can support as many or as few languages as they think their target market requires.

  • Vendors are allowed (but not required) to provide localization mechanisms that enable users or third parties to extend the set of supported languages.

Nowhere in the XSLT specification does it say that implementers must provide facilities for users to define their own extensions. Many implementations will choose to do so, but to find out what extensibility is permitted by the language, we need to look at two things: firstly, the set of information that is defined to be part of the context or environment, and secondly, the features of the language whose behavior is implementation defined. There are detailed lists of these features in the W3C specification, but they fall into a few broad categories.

  • Some features of the language are optional, in the sense that conformant processors are not required to provide them. For example, a processor can choose not to implement schema-aware processing, and it can choose not to implement the disable-output-escaping attribute or the namespace axis in XPath.

  • Interfaces between the XSLT processor and the outside world are generally implementation defined. This includes the mechanisms for invoking the XSLT processor and delivering its results, the mechanism for reporting errors, and the details of how URIs are interpreted in constructs such as <xsl:include> , <xsl: import> , <xsl:import-schema> , and the document() and doc() functions.

  • The XSLT vocabulary is extensible in five key areas. In each of these cases, the vendor can extend the vocabulary and, if they wish, they can also enable users or third parties to extend it:

  • Extension functions: The set of functions that can be called from XPath expressions, and any mechanisms for adding additional functions, are implementation defined, so long as any functions outside the language-defined core are in a separate namespace.

  • Extension instructions: The set of instructions that can appear in a sequence constructor is extensible, so long as the namespace used for any extension instructions is declared in the stylesheet in an «extension-element-pref ixes » attribute.

  • Extension attributes: Additional attributes can be added to any XSLT element, so long as they are in a separate namespace. There are rules limiting the effect that such attributes may have: essentially , they must not change the result of the transformation except to the extent that the W3C specification leaves the result explicitly implementation defined.

  • Extension declarations: Additional top-level declarations can be defined in the stylesheet, provided that the element name is in a separate namespace. These are subject to the same constraints as extension attributes.

  • Extension types: Additional types can be made available. This feature is defined primarily so that extension functions can return application-oriented objects (for example, a sql:connect() function might return an object of type sql: databaseConnection ), but there are no limits on how the facility might be used.

  • The set of collations that can be used for sorting and comparing strings is implementation defined.

  • Many localization attributes, for example those used to control the formatting of dates and numbers , have an implementation-defined range of possible values.

When the specification says that the behavior of a particular feature is implementation-defined, this places an onus on the vendor of a conformant product, to describe in the product documentation what choices they have made. There are also some features of the language that are implementation dependent: the difference here is that vendors are not expected to document the exact behavior of the product. An example of an implementation-dependent feature is the maximum depth of recursion that is permitted. This will depend on a great many factors outside the software vendor's direct control, so it's not reasonable to expect a definitive statement.




XSLT 2.0 Programmer's Reference
NetBeansв„ў IDE Field Guide: Developing Desktop, Web, Enterprise, and Mobile Applications (2nd Edition)
ISBN: 764569090
EAN: 2147483647
Year: 2003
Pages: 324

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net