XSLT and XPath function reference in alphabetical order

(Excerpt from “XSLT 2.0 & XPath 2.0” by Frank Bongers, chapter 5, translated from German)

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

system-property

Category:

Information on the runtime environment

Origin:

XSLT 1.0

Return value:

Depending on the queried property, the function returns a xs:string string; the value of the appropriate system property.

Call/Arguments:

system-property($propertyIdentifier)

$propertyIdentifier:

Obligatory. The argument is a xs:string string which is interpreted as QName. Therefore, the input value must lexically correspond to the xs:QName type, which means it must contain a prefix portion and a local identifier. The QName is expanded according to the namespace being valid for the location of the call. If there is a system property of this name, the function returns its value, otherwise the empty string.

Purpose of use:

The function returns as a string the value applicable for the runtime environment of that system property whose identifier was passed on to the function. Since the identifier shall be a QName, it must have a prefix.

Default properties with xsl prefix must be in the XSLT namespace:

"http://www.w3.org/1999/XSL/Transform"

Application under XSLT 1.0:

A XSLT processor following the standards supports (at least) three system property values.

• xsl:version
  the supported XSLT version

• xsl:vendor
  the name of the manufacturer or the vendor

• xsl:vendor-uri
  the web address under which the vendor can be found

Application under XSLT 2.0:

For XSLT 2.0 the properties listed above remain valid. In this version further properties with product and vendor indications come in addition. A XSLT 2.0 compliant processor must also provide the two following indications – any other (older) processors return an empty string for these.

• xsl:product-name
  the name of the implementation allocated by the manufacturer

• xsl:product-version
  the version number of the implementation

Moreover, system properties are introduced concerning the technical properties of the processor. For this purpose, the processors are divided into categories like Basic XSLT Processor or Schema Aware Processor.

• xsl:is-schema-aware
  returns the string "yes" for a Schema Aware Processor, provided that the processor is able to allow a schema (of whatever kind) during the processing. A processor which cannot allow any schemata (but perhaps DTDs), is regarded as Basic XSLT Processor. It returns the string "no" for xsl:is-schema-aware.

• xsl:supports-serialization
  has the return value "yes" if the processor supports the serialisation according to the specifications, otherwise "no".

• xsl:supports-backwards-compatibility
  returns the string "yes" in case of processors supporting backwards compatibility, otherwise "no".

Further system properties may be provided by the manufacturer, however, these must not be available in the XSLT namespace and, as a consequence, must not be provided with the xsl: prefix.

Example 1 – query of the XSLT version of the implementation:

In this example the supported XSLT version status is queried with the help of the function. If it is XSLT 1.0, the number 1 is returned.

Example 2 – hide instruction from the old processor:

If the processor has a version status earlier than 2.0, the test fails and the processor skips this block.

Function definition:

XSLT 1.0:

system-property(string) => object

XSLT 2.0:

system-property($property-name as xs:string) as xs:string

Possible compatibility problems XSLT 2.0 to XSLT 1.0:

Both versions are identical, except for the number of supported properties. However, a XSLT processor which returns the value »2.0« for the version query must completely correspond to the specification.