WAS v8.5 > Develop applications > XML applications > Use the XML API to perform operations > Performing basic operations > Overview of the XML API

XSLT 2.0, XPath 2.0, and XQuery 1.0 implementation-specific behaviors

Implementation-defined behaviors.

This table lists XSLT 2.0, XPath 2.0, and XQuery 1.0 implementation-defined behaviors for the API.

Feature Description Specification Error Code Documented Behavior
multi preserve-strip-space matched It is a recoverable dynamic error if an element in the source document matches both an xsl:strip-space and an xsl:preserve-space declaration. XSLT 2.0
Section 4.4 		XTRE0270 The processor does not return an error and recovers by selecting the xsl:strip-space or xsl:preserve-space declaration that occurs last in declaration order.
pattern evaluation Any dynamic error or type error that occurs during the evaluation of a pattern against a particular node is treated as a recoverable error even if the error would not be recoverable under other circumstances. The optional recovery action is to treat the pattern as not matching that node. XSLT 2.0
Section 5.5.4 		The processor does not return an error and recovers by treating the pattern as not matching that node.
multiple templates matched It is a recoverable dynamic error if the conflict resolution algorithm for template rules leaves more than one matching template rule. The optional recovery action is to select, from the matching template rules that are left, the one that occurs last in declaration order. XSLT 2.0
Section 6.4 		XTRE0540 The processor does not return an error and recovers by selecting the template that occurs last in declaration order.
invalid value-xml space It is a recoverable dynamic error if the name of a constructed attribute is xml:space and the value is not either default or preserve. The optional recovery action is to construct the attribute with the value as requested. This applies whether the attribute is constructed using a literal result element or using the xsl:attribute, xsl:copy, or xsl:copy-of instructions. XSLT 2.0
Section 11.1.2 		XTRE0795 The processor does not return an error and constructs the attribute with the value as requested.
invalid fragment in document uri When a URI reference supplied to the document function contains a fragment identifier, it is a recoverable dynamic error if one of the following is true:

  • the media type is not one that is recognized by the processor
  • the fragment identifier does not conform to the rules for fragment identifiers for that media type
  • if the fragment identifier selects something other than a sequence of nodes (if it selects a range of characters within a text node, for example)

The optional recovery action is to ignore the fragment identifier and return the document node. (Note the recovery option is different from that in XSLT 1.0)

XSLT 2.0
Section 16.1 		XTRE1160 The processor ignores the fragment identifier and returns the document node. No warning is returned.
same resource for multiple results It is a recoverable dynamic error for a transformation to generate two or more final result trees with URIs that identify the same physical resource. The optional recovery action is implementation-dependent because it may be impossible for the processor to detect the error. XSLT 2.0
Section 19.1 		XTRE1495 The processor returns an error.
read and write to same resource It is a recoverable dynamic error for a stylesheet to write to an external resource and read from the same resource during a single transformation, whether or not the same URI is used to access the resource in both cases. The optional recovery action is implementation-dependent; implementations are not required to detect the error condition. XSLT 2.0
Section 19.1 		XTRE1500 The processor does not attempt to detect this error condition.
disable output escaping not supported It is a recoverable dynamic error if an xsl:value-of or xsl:text instruction specifies that output escaping is to be disabled and the implementation does not support this. The optional recovery action is to ignore the disable-output-escaping attribute. XSLT 2.0
Section 20.2 		XTRE1620 The processor does not provide the ability to disable output escaping and ignores the disable-output-escaping attribute without warning.
disable output escaping for not serialized It is a recoverable dynamic error if an xsl:value-of or xsl:text instruction specifies that output escaping is to be disabled when writing to a final result tree not being serialized. The optional recovery action is to ignore the disable-output-escaping attribute. XSLT 2.0
Section 20.2 		XTRE1630 The processor does not provide the ability to disable output escaping and ignores the disable-output-escaping attribute without warning.
integer overflow On overflow and underflow situations during xs:integer arithmetic operations, implementations that support limited-precision integer operations must select from the following options:

  • Always raising an error (FOAR0002)
  • Providing an implementation-defined mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2 		FOAR0002 The processor provides a mechanism to enable overflow detection for integer operations through the com.ibm.xml.xapi.XStaticContext.setIntegerMathMode(int) method, which can be called with the constants INTEGER_MATH_MODE_OVERFLOW_DETECTION or INTEGER_MATH_MODE_LIMITED_PRECISION (defined on the XStaticContext interface) to choose between the two options. A third option, INTEGER_MATH_MODE_ARBITRARY_PRECISION, is provided to allow arbitrary precision integers.
double float overflow For xs:float and xs:double arithmetic operations, overflow behavior must conform to IEEE 754-1985, which allows the following options:

  • Raising an error (FOAR0002) using an overflow trap

  • Returning INF or -INF

  • Returning the largest (positive or negative) non-infinite number

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2 		  The processor returns INF or -INF.
double float underflow For xs:float and xs:double arithmetic operations, underflow behavior must conform to IEEE 754-1985, which allows the following options:

  • Raising an error (FOAR0002) using an underflow trap

  • Returning INF or -INF

  • Returning 0.0E0, +/- 2**Emin, or a denormalized value where Emin is the smallest possible xs:float or xs:double exponent

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2 		  The processor returns 0.0E0.
invalid use of doctype-system or standalone attr It is a serialization error to specify the doctype-system parameter or to specify the standalone parameter with a value other than omit if the instance of the data model contains text nodes or multiple element nodes as children of the root node. The serializer must either signal the error or recover by ignoring the request to output a document type declaration or standalone parameter. SR
Section 5 		SEPM0004 The processor returns a serialization error.
invalid xml output encoding A serialization error occurs if the output method is XML and an output encoding other than UTF-8 or UTF-16 is requested and the serializer does not support that encoding. The serializer must return the error (SESU0007) or recover using UTF-8 or UTF-16 instead. SR
Section 5.1.2 		SESU0007 The processor returns a serialization error.
error or recovery Some dynamic errors are classed as recoverable errors. When a recoverable error occurs, the processor may signal the error (by reporting the error condition and terminating execution) or take a defined recovery action and continue processing. XSLT 2.0
Section 2.9 		The processor recovers from many of the recoverable errors but signals an error in some cases. Consult this table to determine the implementation-defined behavior of each type of recoverable error.
signal type errors statically Whether or not type errors are signaled statically is implementation defined. XSLT 2.0
Section 2.9 		The processor detects type errors statically whenever possible; but there are cases where the error cannot be detected at compile time. In these cases, the error is detected at run time.
handling serialization errors The handling of serialization errors is implementation defined. XSLT 2.0
Section 20 		Error messages are sent to a com.ibm.xml.xapi.XMessageHandler implementation that has been registered using the setXMessageHandler method on the com.ibm.xml.xapi.XDynamicContext interface.
base output URI The way in which a base output URI is established is implementation defined. XSLT 2.0
Section 2.3   		Users can set the base output URI using the setBaseOutputURI method on the com.ibm.xml.xapi.XDynamicContext interface.
extension attributes Implementations may allow extension attributes to modify the behavior of extension functions and extension instructions or to influence the behavior of the serialization methods xml, xhtml, html, or text to the extent the behavior of the serialization method is implementation defined or implementation-dependent. XSLT 2.0
Section 3.3 		The processor recognizes the indent-amount attribute on xsl:output declarations to specify how many spaces are used for each indentation level when indentation is enabled. The attribute must be from one of the following namespaces:

  • http://www.ibm.com/xmlns/prod/xltxe-j
  • http://xml.apache.org/xalan
  • http://xml.apache.org/xslt

See the additional serialization params item later in the table.

user-defined data elements An implementation may attach an implementation-defined meaning to user-defined data elements that appear in particular namespaces. The set of namespaces that are recognized for such data elements is implementation defined. XSLT 2.0
Section 3.6.2 		The processor does not recognize any user-defined data elements.
user-defined types Support for additional user-defined or implementation-defined types is implementation defined. XPath 2.0 Data Model
Section 2.6 		A schema-aware processor is supported.
undefined type behavior Some typed values in the data model are undefined. Attempting to access an undefined property is always an error. Behavior in these cases is implementation defined and the host language is responsible for determining the result. XPath 2.0 Data Model
Section 2.5.2, Bullet 4.d 		FOTY0012 The processor returned an error. Error messages are sent to a com.ibm.xml.xapi.XMessageHandler implementation that has been registered using the setXMessageHandler method on the com.ibm.xml.xapi.XDynamicContext interface.
namespace node representation Representation of namespaces, that is whether or not they are represented as nodes, is implementation dependent. XPath 2.0 Data Model
Section 6.4 		The namespace axis is supported.
locate stylesheet module After resolving against the base URI, the way in which the URI reference from thehref attribute of an xsl:include or xsl:import declaration is used to locate a representation of a stylesheet module and the way in which the stylesheet module is constructed from that representation are implementation defined. In particular, which URI schemes are supported, whether fragment identifiers are supported, and what media types are supported are implementation defined. XSLT 2.0
Section 3.10.1 		Users may provide an com.ibm.xml.xapi.XSourceResolver implementation through the com.ibm.xml.xapi.XStaticContext. setSourceResolver(XSourceResolver) method. The XSourceResolver is used by the processor to resolve URIs from xsl:include and xsl:import declarations (therefore, the user may decide which URIs to support), and its getSource(String, String) method must return a JAXP Source object.

If no XSourceResolver is given, the processor handles the file URI scheme and those supported by the java.net.URL.openConnection() method. A URI fragment may be used to select an embedded stylesheet module within a source XML document. The fragment must identify an xsl:stylesheet element in the document using the value of one of its attributes that is an xml:id attribute or is defined in a DTD as being of type ID or is defined in a schema as being of type xs:ID. There is no built-in support for non-XML media types, but users may use an XSourceResolver implementation to provide the processor with an XML representation of non-XML data.

extension functions Extension functions

The XSLT 2.0 specification defines how extension instructions and extension functions are invoked, but the facilities for creating new extension instructions and extension functions are implementation defined.

XSLT 2.0
Section 18.1 		Extension functions are supported through the processor's XStaticContext.declareFunction and XDynamicContext.bindFunction methods. Alternatively, it is also possible to declare extension functions directly within a stylesheet or query. The old style of extension functions supported in the parser and the processor are also supported for backwards compatibility; however, only 1.0 types are supported with the old style. See the API documentation for more information. It is recommended that you declare extension functions directly in your stylesheet or through the API for extension functions whenever possible rather than use the old style.
extension instructions Extension instructions

The XSLT 2.0 specification defines how extension instructions and extension functions are invoked, but the facilities for creating new extension instructions and extension functions are implementation defined.

XSLT 2.0
Section 18.2 		XTDE1450 User-defined extension instructions are not supported. Extension instructions must be protected with a fallback instruction; otherwise, the stylesheet will fail to compile. The redirect extension is supported for backwards compatibility; however, IBM recommends that we use the XSLT 2.0 xsl:result-document instruction because this is more portable.
backwards-compatiblility Whether a particular XSLT 2.0 implementation supports backwards-compatible behavior is implementation defined. XSLT 2.0
Section 3.8 		The backwards-compatibility feature as described in the XSLT 2.0 specification is supported.
in-scope collations for use-when In-scope collations for use-when expressions XSLT 2.0
Section 3.12 		The only collation available during the evaluation of a use-when is the Unicode code-point collation.
current date time for use-when Current date and time for use-when expressions XSLT 2.0
Section 3.12 		The current date time is the current date time of the system as retrieved by calling the java.util.GregorianCalendar getInstance() method.
implicit timezone for use-when Implicit time zone for use-when expressions XSLT 2.0
Section 3.12 		The implicit time zone is the time zone of the system as retrieved by calling the java.util.TimeZone getDefault() method.
maximum number of decimal digits Maximum number of total digits in decimal digits is implementation defined , but they must be at least 18 digits. XSLT 2.0
Section 4.6 		The implementation uses the java.math.BigDecimal class, which supports nearly unlimited precision, except the number of digits to the right of the decimal place is limited to Integer.MAX_VALUE. Truncation is only required in the case of division, where there is the possibility of non-terminating decimals. The precision of the fractional part of the result is limited to 18 digits. The rounding mode in this case is ROUND_HALF_UP, where discarded fractions of 0.5 or later are rounded up (away from zero) and lesser fractions are rounded down.
year component values For the xs:date, xs:time, xs:dateTime, xs:gYear, and xs:gYearMonth types: the range of values of the year component (which must be at least +0001 to +9999), and the maximum number of fractional second digits (which must be at least 3) XSLT 2.0
Section 4.6 		The year component of the xs:date, xs:dateTime, xs:gYear, and xs:gYearMonth types has the range -(10^9-1) to (10^9)-1. Maximum number of fractional seconds digits supported for the xs:time and xs:dateTime types is three.
duration For the xs:duration type: the maximum absolute values of the years, months, days, hours, minutes, and seconds components XSLT 2.0
Section 4.6 		Maximum absolute values for the duration components are:

  • year: 178956970
  • month: 2147483647
  • day: 106751991167
  • hour: 2562047788015
  • minute: 153722867280912
  • second: 9223372036854775

Three digits of precision are supported for milliseconds.

year month duration For the xdt:yearMonthDuration type: the maximum absolute value expressed as an integer number of months XSLT 2.0
Section 4.6 		Maximum absolute value for the xs:yearMonthDuration type is 2147483647 months.
day time duration For the xdt:dayTimeDuration type: the maximum absolute value expressed as a decimal number of seconds XSLT 2.0
Section 4.6 		Maximum absolute value for the xs:dayTimeDuration type is 9223372036854775 seconds.
value maximum length For the xs:string, xs:hexBinary, xs:base64Binary, xs:QName, xs:anyURI, xs:NOTATION types and types derived from them: the maximum length of the value XSLT 2.0
Section 4.6 		The theoretical maximum length is 2^31 - 1; however, the system is likely to run out of memory long before that limit is reached.
sequence length Maximum number of items in a sequence XSLT 2.0
Section 4.6 		The theoretical maximum number of items is 2^31 - 1; however, the system is likely to run out of memory long before that limit is reached.
statically known collations Set of in-scope collations XSLT 2.0
Section 5.4.1

XPath 2.0
Section 2.1.1

XQuery 1.0
Section 2.1.1

Any URI is considered to be in the set of in-scope collations. Every URI used as a collation URI must be associated with a Java Collator at execution time.
implicit timezone Implicit time zone XSLT 2.0
Section 5.4.3.2

XPath 2.0
Section 2.1.2

XQuery 1.0
Section 2.1.2

The implicit time zone can be set using the XDynamicContext.setImplicitTimeZone(Duration) method in the processor. If the implicit time zone is not set, the system time zone is used as retrieved through the java.util.TimeZone.getDefault() method.
default collection Default collection

This is the sequence of nodes that would result from calling the fn:collection function with no arguments. The value of the default collection may be initialized by the implementation.

XSLT 2.0

XPath 2.0
Section 2.1.2

FODC0004 The default collection is determined by the XCollectionResolver registered with the XDynamicContext. If no XCollectionResolver is registered an error is returned and the empty sequence is used. For more information about the XCollectionResolver interface, refer to the API documentation.
stylesheet parameter Supply stylesheet parameter value when executing a transformation

A top-level xsl:param element declares a stylesheet parameter. A stylesheet parameter is a global variable with the additional property that its value can be supplied by the caller when a transformation is initiated.

XSLT 2.0
Section 9.5 		If a value for a parameter is bound in the XDynamicContext, that value is used; otherwise, the default value specified in the stylesheet for the parameter is used.

To bind values to parameters, use the XDynamicContext.bind() methods.

stylesheet function override mechanism Override a stylesheet function to a function provided by the implementer; pertains to the xsl:function element

The optional override attribute defines what happens if this function has the same name and arity as a function provided by the implementer or made available in the static context using an implementation-defined mechanism. If the override attribute has the value yes, this function is used in preference; if it has the value no, the other function is used in preference. Default is yes. Specifying override="yes" ensures interoperable behavior—the same code will execute with all processors. Specifying override="no" is useful when writing a fallback implementation of a function that is available with some processors but not others—it allows the vendor's implementation of the function (or a user's implementation written as an extension function) to be used in preference to the stylesheet implementation.

XSLT 2.0
Section 10.3 		If the override attribute had the value of yes, stylesheet functions can override the following:

  • extension functions declared in the XStaticContext using the XStaticContext.declareFunction() methods and bound in the XDynamicContext using the XDynamicContext.bindFunction() methods
  • old style extension functions supported in XSLT4J and XL TXE-J 1.0

    See Use extension functions.

  • EXSLT extension functions implemented by the processor

Stylesheet functions cannot be made to override any of the core functions defined in the XSLT 2.0 specification or the XQuery 1.0 and XPath 2.0 Functions and Operators specification.

normalize copied xml id When an xml:id attribute is copied using either the xsl:copy or xsl:copy-of instruction, it is implementation defined whether the value of the attribute is subjected to attribute value normalization—that is, effectively applying the normalize-space XQuery 1.0 and XPath 2.0 Functions and Operators function. XSLT 2.0
Section 11.9 		Neither the xsl:copy and xsl:copy-of instructions apply the normalize-space function on xml:id attributes; so all white spaces are preserved.
numbering sequences supported Numbering sequences supported

Which numbering sequences, additional to those listed previously, are supported is implementation defined. If an implementation does not support a numbering sequence represented by the given token, it must use a format token of 1.

XSLT 2.0
Section 12.3 		The processor only supports the standard sets of numbering sequences.
bounds on range of numbers Lower and upper bounds on the range of numbers

For the standard numbering sequences, any upper bound imposed by the implementation must not be less than 1000 (one thousand) and any lower bound must not be greater than 1. Numbers that fall outside this range must be formatted using the format token 1. The numbering sequence associated with the format token 1 has a lower bound of 0 (zero).

XSLT 2.0
Section 12.3

  • Alphabet values: arbitrary precision when in integer arbitrary precision mode, otherwise 0 to 2^63 - 1
  • Digit values: arbitrary precision when in integer arbitrary precision mode, otherwise 0 to 2^63 - 1
  • Roman values: 0 - 9999
  • Word number: 0 - 19999

default language for numbering Default language for numbering

The lang attribute specifies which language's conventions are to be used; it has the same range of values as xml:lang (see the XML 1.0 specification). If no lang value is specified, the language used is implementation defined.

The set of languages for which numbering is supported is implementation defined. If a language is requested not supported, the processor uses the language that it would use if the lang attribute were omitted.

XSLT 2.0
Section 12.3 		The default language for number formatting is always set to en-US.
languages for numbering Set of languages for numbering

Many numbering sequences are language sensitive.

XSLT 2.0
Section 12.3 		The languages supported are based on International Component Unicode (ICU) and languages supported by the JVM.
combinations for numbering Combinations of values of the format token, the language, and the ordinal attribute for numbering XSLT 2.0
Section 12.3 		The processor only supports the ordinal value of yes. Any other values for the ordinal attribute are ignored as if the ordinal attribute was not specified.
data-type for sort Effect of the data-type attribute for xsl:sort

If this has the effective value text, the atomized sort key values are converted to strings before being compared. If it has the effective value number, the atomized sort key values are converted to doubles before being compared. The conversion is done using the string-FO or number-FO function as appropriate. If the data-type attribute has any other effective value, the value must be a lexical QName with a non-empty prefix and the effect of the attribute is implementation defined.

XSLT 2.0
Section 13.1.2 		The supported values for the data-type attribute are 'text' and 'number'. For any other valid values, a warning message is issued and the data-type attribute is ignored.
collation uri Manner in which the URI is associated with an actual collation rule or algorithm

The lang and case-order attributes are ignored if a collation attribute is present. But in the absence of a collation attribute, these attributes provide input to an implementation-defined algorithm to locate a suitable collation.

Facilities in XSLT 2.0 and XPath 2.0 that require strings to be ordered rely on the concept of a named collation. A collation is a set of rules that determine whether two strings are equal and, if not, which of them is to be sorted before the other. A collation is identified by a URI, but the manner in which this URI is associated with an actual rule or algorithm is implementation defined

XSLT 2.0
Section 13.1.3 		Collation URIs are associated with a Java Collator through the API using one of the XDynamicContext.bindCollation methods.
lang case-order determine collation Which lang and case-order attributes determine a collation algorithm for sort XSLT 2.0
Section 13.1.3 		The processor retrieves a locale based on the value of the lang attribute. It then creates a Java collator using the java.text.Collator.getInstance(Locale) method.

The compare method of the collator is overridden to handle the case-order attribute if specified. If the lang attribute was not specified, the processor proceeds as previous using the default locale returned by the Java method Locale.getDefault().

default collation for sort Default collation for sort

If none of the collation, lang or case-order attributes is present in xsl:sort, the collation is chosen in an implementation-defined way. It is not required the default collation for sorting should be the same as the default collation used when evaluating XPath expressions. (see Section 5.4.1: Initializing the Static Context and Section 3.6.1: The default-collation attribute)

XSLT 2.0
Section 13.1.3 		The processor uses the default locale returned by the Java method Locale.getDefault() to create a Java collator using the java.text.Collator.getInstance(Locale) method.
recognized media types Set of media types recognized by a processor XSLT 2.0
Section 16.1 		The processor only supports XML files.
picture fallback in date formatting Fallback representation for picture string in the date formatting functions; the format token n, N, or Nn, that indicates the value of the component is to be output by name, in lowercase, uppercase, or title-case respectively

Components that can be output by name include (but are not limited to) months, days of the week, time zones, and eras. If the processor cannot output these components by name for the chosen calendar and language, it must use an implementation-defined fallback representation.

XSLT 2.0
Section 16.5.1 		The processor will output [Calendar: AD] as the fallback.
set supported in date formatting functions Languages, calendars, and countries that are supported in the date-formatting functions XSLT 2.0
Section 16.5.2, first paragraph

  • Supported calendars: AD, ISO, BE
  • Supported languages and locales: those returned by java.util.Locale.getAvailableLocales()

defaults in date formatting functions Default language, calendar, and country in the date-formatting functions if arguments are omitted or empty XSLT 2.0
Section 16.5.2, first paragraph

  • Default calendar: AD
  • Default language and locale: those specified by java.util.Locale.getDefault()

default language in date formatting functions Default language in the date-formatting functions

If the language argument is omitted, set to an empty sequence, or set to an invalid value or a value the implementation does not recognize, the processor uses an implementation-defined language.

XSLT 2.0
Section 16.5.2, fourth paragraph 		See defaults in date formatting functions.
names abbrev in language in date formatting functions Names and abbreviations in the date-formatting functions XSLT 2.0
Section 16.5.2, seventh paragraph 		The International Components for Unicode (ICU) website has a Locale Explorer containing links to tables for each supported locale. The processor uses the short names for the names of the days of the week and the months specified in those tables as the abbreviated forms, and it uses the long names as the unabbreviated forms.
calendar behavior in date formatting functions Behavior of calendar in date-formatting functions XSLT 2.0
Section 16.5.2, tenth paragraph 		The processor does not support any calendars with a non-null namespace URI. If the QName supplied has a prefix, the AD calendar will be used.
default calendar in date formatting functions Default calendar in date-formatting functions XSLT 2.0
Section 16.5.2, eleventh paragraph 		See defaults in date formatting functions.
supported calendars in date formatting functions Set of calendars supported in date-formatting functions XSLT 2.0
Section 16.5.2, first paragraph following table of calendars 		See set supported in date formatting functions.
system property values Actual values returned from system properties XSLT 2.0
Section 16.5.5, second paragraph following the bulleted list 		The value of the system property:

  • xsl:version is 2.0
  • xsl:vendor is IBM Corporation
  • xsl:vendor-url is http://www.ibm.com/
  • xsl:product-name is XL Transform and Query Engine for Java
  • xsl:product-version is 2.0
  • xsl:is-schema-aware is yes
  • xsl:supports-serialization is yes
  • xsl:supports-backwards-compatibility is yes
  • xsl:supports-namespace-axis is yes

set of system properties Set of system properties XSLT 2.0
Section 16.6.5 and Erratum XT.E14 		The processor supports the following:

  • All the system properties defined in Section 16.6.5 of the XSLT 2.0 specification
  • New optional xsl:supports-namespace-axis property defined by XSLT Erratum XT.E14

xslmessage Way in which an xsl:message instruction sends a message XSLT 2.0
Section 17, first paragraph 		According to Section 17 of the XSLT 2.0 specification, xsl:message sends a message in an implementation-defined way to an implementation-defined destination. The processor uses the string value of the document node created by the xsl:message instruction as the message.

If the user did not supply an instance of com.ibm.xml.xapi.XMessageHandler on the com.ibm.xml.xapi.XDynamicContext for the transformation, the message is written to the System.err output stream; and if the effective value of the terminate attribute was yes, the transformation throws an exception. If the user supplied an instance of com.ibm.xml.xapi.XMessageHandler, the message is passed on that object's report() method. See the API documentation for more information.

xslmessage destination Output destination for document created by an xsl:message instruction XSLT 2.0
Section 17, first paragraph 		See xslmessage.
error handling in ext functions Consequences of an error for an extension function to return a string containing characters that are not XML XSLT 2.0
Section 18.1.2, paragraph following the third note 		Section 18.1.2 of the XSLT 2.0 specification  permits several behaviors when an extension function returns a string containing characters that are not permitted in XML, including treating them as if they were permitted. That is the behavior the processor implements.
external objects Way in which external objects are represented in the type system XSLT 2.0
Section 18.1.3, second paragraph 		Data objects whose values are of types that do not map to built-in types as described in Map XML types to Java types are not supported.
final result tree delivery Way in which a final result tree is delivered to an application XSLT 2.0
Section 19, third paragraph 		As described in Section 19.1 of the XSLT 2.0 specification, an implementation may allow a final result tree to be serialized or provide additional mechanisms through which they may be processed.

In the processor, a final result tree may be serialized or it may delivered to an application in the form of a java.xml.transform.Result object or a com.ibm.xml.xapi.XSequenceCursor object. If the URI of the final result tree is not equal to the base output URI, and:

  • the user supplied a com.ibm.xml.xapi.XResultResolver on the com.ibm.xml.xapi.XDynamicContext, the result tree will be delivered to the application in the form of the javax.xml.transform.Result object returned by com.ibm.xml.xapi.XResultResolver.getResult();
  • otherwise, the result tree is serialized to the location specified by the URI using java.net.URL.openConnection().

    A final result tree whose URI is equal to the base output URI is delivered to the application using any javax.xml.transform.Result object specified on the com.ibm.xml.xapi.XExecutable.execute method used to invoke the transformation, or as the com.ibm.xml.xapi.XSequenceCursor returned from the com.ibm.xml.xapi.XExecutable.execute() method if that method's signature contains no javax.xml.transform.Result argument.

    If the result tree is delivered in the form of a javax.xml.transform.stream.StreamResult, it is serialized to the location specified by the StreamResult; if it is delivered as an instance of any other subclass of Result or as an XSequenceCursor, the result tree is delivered in the form appropriate for that API.

    Refer to the API documentation for additional information.

URI restriction Restrictions on form of absolute URI used in an href XSLT 2.0
Section 19.1, third paragraph following the second note 		As described in Section 19.1 of the XSLT 2.0 specification, an implementation may place implementation-defined limitations on an absolute URI that is the value of an href attribute on an xsl:result-document instruction. With the processor,

  • If the user supplies an com.ibm.xml.xapi.XResultResolver on the com.ibm.xml.xapi.XDynamicContext in which the stylesheet is evaluated, there are no limitations on the form of such an absolute URI.

  • If there is no user-supplied XResultResolver, the only restrictions are that if the href attribute is an absolute URI that:

    • uses the file protocol, the user must have permission to open an output stream to that file
    • uses some other protocol, the user must have permission to create an output stream to the URI, using the Java equivalent new java.net.URL(href).openConnection().getOutputStream()

final result tree location Location to which final result trees are serialized XSLT 2.0
Section 2.3 see base output URI 		By default, final result tree URIs will be interpreted relative to the base URI of the main output document. If another location is desired, an XResultResolver implementation can be registered with the dynamic context to implement user-defined behaviors. Use the XDynamicContext.setResultResolver() method to register the XResultResolver implementation. The base URI used can also be changed by calling the XDynamicContext.setBaseOutputURI() method.
default output encoding Default of the encoding attribute in xsl:output XSLT 2.0
Section 20 		The default output encoding is UTF-8.
byte-order-mark for UTF-8 Byte-order-mark for UTF-8 XSLT 2.0
Section 20 		Default is no, meaning that no BOM is produced at the start of UTF-8 files.
additional normalization form Additional normalization form for serialization XSLT 2.0 and XQuery 1.0 Serialization
Section 19.1
Section 20
Section 5.1.8 		No implementation-defined normalization forms are provided.
output version Permitted and default value of the version attribute in xsl:output XSLT 2.0
Section 20 		The default for XML or XHTML is 1.0; users may explicitly specify 1.0 or 1.1. For HTML, the default is 4.0.
static-typing in stylesheet Interaction of XSLT 2.0 stylesheets with the static typing feature of XPath 2.0 XSLT 2.0 and XPath 2.0
XSLT 2.0 Section 21
XPath 2.0 Section F.1 		This XSLT processor does not currently have a mechanism for requesting that its XPaths perform static typing.
built in types Type definitions available within a stylesheet XSLT 2.0
Section 3.13 		The processor is schema aware as defined in Section 3.13 of the XSLT 2.0 specification.
namespace for additional error codes Namespace used if additional error QNames are defined by the implementation XSLT 2.0
Section 2.9 		When appropriate, the processor does include the specified error code or code(s) in the text of its messages within square brackets. Additional errors are generally expressed similarly but without a specification prefix on the error identifier.

Error conditions are not presented as QNames; applications that wish to respond to errors programmatically must parse these error identifiers off the front of the error-message strings.

unparsed text encoding Mechanism for determining encoding of an external source XSLT 2.0
Section 16.2 		The processor does not implement any additional heuristics. Encoding resolution proceeds immediately to step 5, and UTF-8 is assumed.
available documents Mechanism for obtaining a document node and a media type given an absolute URI XSLT 2.0
Section 2.3
Section 16.1 		The default source resolution behavior for documents loaded using the XPath fn:doc function is to resolve relative URIs based on the base URI from the static context. If the base URI is not available, the current working directory is used. Absolute URIs are used unchanged. The default source resolution behavior for documents loaded using the XSLT document function is described in the XSLT 2.0 specification Multiple Source Documents. If no base URI is available, the current working directory is used. If the application needs to either constrain or extend these behaviors, it is possible to plug in an implementation of XSourceResolver to the XDynamicContext through the setSourceResolver() method.
additional output methods Support for implementation-defined output method XSLT 2.0 and XQuery 1.0 Serialization
Section 3 		The processor does not implement any additional output methods.
additional serialization params Effect of additional serialization parameters on the output of the serializer XSLT 2.0 and XQuery 1.0 Serialization
Section 3
XSLT 2.0 Section 20 		The processor implements the following additional serialization parameters:

  • INDENT AMOUNT:

    Number of spaces to use when the indent serialization parameter is enabled. Use the XOutputParameters.setIndentAmount() method or the xalan:indent-amount can be specified in the xsl:output element of an XSL stylesheet using the indent-amount attribute.

  • BC MODE:

    Enables backwards-compatibility mode for the serializer. If enabled and no output method is specified, XML will be used as a default. If disabled, the rules of XSLT 2.0 will be followed when no output method is specified. Use the XOutputParameters.setBackwardsCompatible() method to enable. For XSL stylesheets where the version is less than 2.0, backwards-compatibility mode is enabled by default.

additional normalization-form Support for additional Unicode Normalization form XSLT 2.0 and XQuery 1.0 Serialization
Section 5.1.8 		No implementation-defined normalization forms are provided.
option in encoding phase Effect of an option that allows the encoding phase to be skipped so the result of serialization is a stream of Unicode characters XSLT 2.0 and XQuery 1.0 Serialization
Section 4 		No such option is provided by the processor.
cdata sec mechanism Alternative mechanism requested by the user to create CDATA sections SR
Section 5.1.4 of XSLT 2.0 and XQuery 1.0 Serialization 		The processor does not provide an alternative mechanism for creating CDATA sections.
unicode version Supported version of Unicode XPath 2.0
Appendix D

XQuery 1.0
Appendix D

The processor supports the version of Unicode supported by the host JRE—namely, Unicode Standard Version 4.0 for Java 6 and Unicode Standard v6.0 for Java 7.
trace function Trace function

The destination of the trace output is implementation defined.

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 4 		When using the fn:trace() function, the result will be passed to the com.ibm.xml.xapi.XMessageHandler (formerly com.ibm.xml.xapi.XErrorHandler). It is up to the user to specify their own XMessageHandler to handle the trace results reported by the processor. Trace-message type is indicated by XMessageHandler.TRACE.
recovery for under overflow integer operations Mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value during overflow or underflow arithmetic operations XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2 		The processor provides a mechanism to enable overflow detection for integer operations through the com.ibm.xml.xapi.XStaticContext.setIntegerMathMode(int) method, which can be called with the constants INTEGER_MATH_MODE_OVERFLOW_DETECTION or INTEGER_MATH_MODE_LIMITED_PRECISION to choose between the two options. A third option is provided to allow arbitrary precision integers.
digits truncation If the number of digits in the result of a numeric operation exceeds the number of digits the implementation supports, the result is truncated or rounded in an implementation-defined manner. XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2
Section 3.2.3 of XML Schema Part 2: Datatypes Second Edition 		The implementation uses the java.math.BigDecimal class, which supports nearly unlimited precision except the number of digits to the right of the decimal place is limited to Integer.MAX_VALUE. Truncation is only required in the case of division, where there is the possibility of non-terminating decimals. The precision of the fractional part of the result is limited to 18 digits. The rounding mode in this case is ROUND_HALF_UP, where discarded fractions of 0.5 or later are rounded up (away from zero) and lesser fractions are rounded down.
collation abilities Ability of specified collation to decompose strings into collation units suitable for substring matching is an- implementation-defined-property of a collation. XQuery 1.0 and XPath 2.0 Functions and Operators
Section 7.5 		If the Java Collator specified in a call to the bindCollation method of the XDynamicContext interface is an instance of the RuleBasedCollator class, the associated collation URI can be used with one of the functions that performs collation-based substring matching.
year value limits Maximum number of digits for year values.

All minimally conforming processors must support year values with a minimum of 4 digits (YYYY) and a minimum fractional second precision of 1 millisecond or three digits (s.sss); however, conforming processors may set larger implementation-defined-limits on the maximum number of digits they support in these two situations.

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 10.1.1 		The year component of the types xs:date, xs:dateTime, xs:gYear, and xs:gYearMonth has the range -(10^9-1) to (10^9)-1.
fractional second precision Maximum number of digits for fractional second values XQuery 1.0 and XPath 2.0 Functions and Operators
Section 10.1.1 		Maximum number of fractional seconds digits supported for the xs:time and xs:dateTime types is 3.
doc function Various aspects of the processing provided by fn:doc are implementation defined. Implementations may provide external configuration options that allow any aspect of the processing to be controlled by the user. XQuery 1.0 and XPath 2.0 Functions and Operators
Section 15.5.4 		Users may provide an com.ibm.xml.xapi.XSourceResolver implementation through the com.ibm.xml.xapi.XDynamicContext. setSourceResolver(XSourceResolver) method. The XSourceResolver is used by the fn:doc implementation to resolve URIs (thus the user may decide which URIs to support), and its getSource(String, String) method must return a JAXP Source object. If no XSourceResolver is given, the processor handles the file URI scheme and those supported by the java.net.URL.openConnection() method. It does not process URI fragments. There is no built-in support for non-XML media types, but users may use an XSourceResolver implementation to provide the processor with an XML representation of non-XML data.

DTD validation and schema validation may be applied to the source document depending on the validation setting. The validation setting may be set on com.ibm.xml.xapi.XFactory instances using the setValidating method, and this setting is inherited by objects created by the XFactory. If a com.ibm.xml.xapi.XDynamicContext instance is provided to the execute or executeToList method of a com.ibm.xml.xapi.XExecutable instance, its validation setting is used; otherwise, the setting of the XExecutable instance itself is used. The processor does not provide a recovery mechanism for errors in retrieving the resource or parsing or validating its content.

The processor does not provide an option to relax the requirement for the fn:doc function to return stable results.

decimal operator precision For xs:decimal values, the number of digits of precision returned by the numeric operators is implementation defined. XQuery 1.0 and XPath 2.0 Functions and Operators
Section 6.2, last paragraph 		The number of digits of precision is the minimum required to represent the exact result without rounding, except in the case of division, where the number of digits of precision for the fractional part of the result is limited to 18.
collection doc stability User option to evaluate the function without a guarantee of stability in addition to the manner in which such user options are provided XQuery 1.0 and XPath 2.0 Functions and Operators
Sections 15.5.4 and 15.5.6 		The processor does not provide an option to relax the requirement for the fn:doc or fn:collection functions to return stable results.
decimal precision Number of decimal digits supported in xs:decimal

The result of casting a string to xs:decimal when the resulting value is not too large or too small but nevertheless has too many decimal digits to be accurately represented, is implementation defined.

XQuery 1.0 and XPath 2.0 Functions and Operators
Section 17.1.1 		The implementation uses the java.math.BigDecimal class, which supports nearly unlimited precision, except the number of digits to the right of the decimal place is limited to Integer.MAX_VALUE. Memory would be exhausted before this limit is reached.
returns warning Circumstances in which warnings are returned, and the ways in which warnings are handled XQuery 1.0 and XPath 2.0 Functions and Operators
Section 2.3

XPath 2.0
Section 2.3.1

XQuery 1.0
Section 2.3.1

The user can provide an implementation of com.ibm.xml.xapi.XMessageHandler using the setMessageHandler()(XMessageHandler) method on either com.ibm.xml.xapi.XStaticContext or com.ibm.xml.xapi.XDynamicContext for static and dynamic warnings respectively. The report(int, String, XSourceLocation, Exception) method of XMessageHandler will be called for each warning, with the first argument equal to XMessageHandler.WARNING.

If no XMessageHandler is provided, warnings are printed to the standard error output stream.

Warnings are returned in situations where the processor takes some action to avoid an error condition, such as substituting a default value for an invalid value, the user might want to correct in the future.

report error Method by which errors are reported to the external processing environment XQuery 1.0 and XPath 2.0 Functions and Operators
Section 2.3

XPath 2.0
Section 2.3.2

XQuery 1.0
Section 2.3.2

The user can provide an implementation of com.ibm.xml.xapi.XMessageHandler using the setMessageHandler()(XMessageHandler) method on either com.ibm.xml.xapi.XStaticContext or com.ibm.xml.xapi.XDynamicContext for static and dynamic errors respectively. The report(int, String, XSourceLocation, Exception) method of XMessageHandler will be called for each error, with the first argument equal to either XMessageHandler.ERROR or XMessageHandler.FATAL_ERROR.

If no XMessageHandler is provided, errors are printed to the standard error output stream.

XML 1.0 or XML 1.1 rules Whether the processor is based on XML 1.0 or XML 1.1 rules for names and supported characters XPath 2.0
Appendix D XQuery 1.0
Appendix D 		  The processor follows XML 1.1 rules for the definitions of NCName and supported characters as well as for end-of-line handling and attribute value normalization.
default order of empty sequences Whether the default handling of empty sequences in "order by" is "empty least" or "empty greatest" XQuery 1.0
Section 3.8.3 		  The processor uses the default set by a call to the XStaticContext method setDefaultOrderForEmptySequences. Otherwise, the default setting is "empty greatest".
pragmas supported The names and semantics of any XQuery extension expressions (pragmas) supported XQuery 1.0
Section 3.14 		XQST0079 The processor does not recognize or support any extension expressions.
options supported The names and semantics of any XQuery option declarations supported XQuery 1.0
Section 4.16 		  The processor currently supports the java-extension option for declaring extension functions within a query. See the API documentation for more information.
external function parameter passing Protocols supported for passing parameters to external functions from XQuery and for returning a result XQuery 1.0
Section 4.15 		  Extension functions are supported through the processor's XStaticContext.declareFunction and XDynamicContext.bindFunction methods. See the API documentation for more information.
invoking serialization The means by which serialization is invoked for the result of evaluating an XQuery query XQuery 1.0
Section 2.2.4 		  If an instance of the javax.xml.transform.stream.StreamResult interface is supplied on an evaluate method of an XQueryExecutable instance, the processor will serialize the result of the query. We can also serialize an XSequenceCursor that results from evaluating a query by calling one of the exportSequence methods.
default serialization parameters The default values of the byte-order-mark, encoding, media-type, normalization-form, omit-xml-declaration, standalone, and version serialization parameters XQuery 1.0
Section 2.2.4
Appendix C.3 		  The settings of the serialization parameters can be specified on an instance of the XOutputParameters interface.

  • The default setting of the byte-order-mark serialization parameter is yes for the UTF-16 encoding, and it is no otherwise.
  • The default setting of the encoding serialization parameter is UTF-8.
  • The default setting of the media-type serialization parameter is text/xml in the case of the xml output method, text/html in the case of the html and xhtml output methods, and text/plain in the case of the text output method.
  • The default setting of the normalization-form serialization parameter is none.
  • The default setting of the omit-xml-declaration serialization parameter is no.
  • The default setting of the standalone serialization parameter is no.
  • The default setting of the version serialization parameter is 1.0 for the xml and xhtml output methods and 4.01 for the html output method.

unsuccessful external function call The effect of an unsuccessful call to an external function XQuery 1.0
Appendix D 		  The processor will first report an error to any instance of the XMessage handler interface supplied and will then throw an exception if a call from XQuery to an external function is unsuccessful for any of (but not limited to) the following reasons:

  • because the function name is not bound to a function definition using the XDynamicContext.bindFunction method
  • the number or types of arguments supplied does not match the number or types expected by the implementation of the function
  • some error or exception is thrown by the implementation of the function

locate module imports The process by which the specific modules to be imported by a module import are identified if the Module Feature is supported (including processing of location hints if any) XQuery 1.0
Section 4.11 		  If an XModuleResolver is registered with the XStaticContext, it is used to get Source objects for the modules. If no XModuleResolver is registered or if it returns null, the processor attempts to load one module for each location hint. Relative URIs are resolved against the base URI from the static context if available. If the base URI is not available, relative location hints are interpreted as file paths relative to the current working directory. Absolute location hints are used as is. If a module cannot be loaded for a particular location hint, the processor moves on to the next hint. An error message is emitted only if no modules can be loaded for a namespace.

The following is implementation-specific information related to XSLT 1.0 support:


+

Search Tips   |   Advanced Search