The XSLT 2.0 engine of XMLSpy conforms to the World Wide Web Consortium's (W3C's) XSLT 2.0 Recommendation of 23 January 2007 and XPath 2.0 Recommendation of 14 December 2010.
The XSLT 2.0 engine is backwards compatible. Typically, the backwards compatibility of the XSLT 2.0 engine comes into play when using the XSLT 2.0 engine to process an XSLT 1.0 stylesheet or instruction. Note that there could be differences in the outputs produced by the XSLT 1.0 Engine and the backwards-compatible XSLT 2.0 engine.
Your XSLT 2.0 stylesheet should declare the following namespaces in order for you to be able to use the type constructors and functions available in XSLT 2.0. The prefixes given below are conventionally used; you could use alternative prefixes if you wish.
XML Schema types
XPath 2.0 functions
Typically, these namespaces will be declared on the xsl:stylesheet or xsl:transform element, as shown in the following listing:
The following points should be noted:
•The XSLT 2.0 engine uses the XPath 2.0 and XQuery 1.0 Functions namespace (listed in the table above) as its default functions namespace. So you can use XPath 2.0 and XSLT 2.0 functions in your stylesheet without any prefix. If you declare the XPath 2.0 Functions namespace in your stylesheet with a prefix, then you can additionally use the prefix assigned in the declaration.
•When using type constructors and types from the XML Schema namespace, the prefix used in the namespace declaration must be used when calling the type constructor (for example, xs:date).
•Some XPath 2.0 functions have the same name as XML Schema datatypes. For example, for the XPath functions fn:string and fn:boolean there exist XML Schema datatypes with the same local names: xs:string and xs:boolean. So if you were to use the XPath expression string('Hello'), the expression evaluates as fn:string('Hello')—not as xs:string('Hello').
The XSLT 2.0 engine is schema-aware. So you can use user-defined schema types and the xsl:validate instruction.
Given below is a description of how the XSLT 2.0 engine handles implementation-specific aspects of certain XSLT 2.0 functions.
Additionally supported encodings are (the Altova-specific): x-base16tobinary and x-base64tobinary.
The function tests for the availability of in-scope functions (XSLT, XPath, and extension functions).
The href argument accepts (i) relative paths for files in the base-uri folder, and (ii) absolute paths with or without the file:// protocol. Additionally supported encodings are (the Altova-specific): x-binarytobase16 and x-binarytobase64. Example: xs:base64Binary(unparsed-text('chart.png', 'x-binarytobase64')).
The href argument accepts (i) relative paths for files in the base-uri folder, and (ii) absolute paths with or without the file:// protocol. Additionally supported encodings are (the Altova-specific): x-binarytobase16 and x-binarytobase64.
|Note:||The following encoding values, which were implemented in earlier versions of RaptorXML's predecessor product, AltovaXML, are now deprecated: base16tobinary, base64tobinary, binarytobase16 and binarytobase64.|