XSLT 2.0, XPath 2.0, and XQuery 1.0 implementation-specific behaviors
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 | 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 | 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 | 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 by using the xsl:attribute, xsl:copy, or xsl:copy-of instructions. | XSLT 2.0 | 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: |
XSLT 2.0 | 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 | 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 | 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 | 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 that is not being serialized. The optional recovery action is to ignore the disable-output-escaping attribute. | XSLT 2.0 | 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: |
XQuery 1.0 and XPath 2.0 Functions and Operators | 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: |
XQuery 1.0 and XPath 2.0 Functions and Operators | 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: |
XQuery 1.0 and XPath 2.0 Functions and Operators | 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 | 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 by using UTF-8 or UTF-16 instead. | SR | 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 | 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 | 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 | 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 | 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 that the behavior of the serialization method is implementation defined or implementation-dependent. | XSLT 2.0 | 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: |
|
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 | 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 | 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 | 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 | The namespace axis is supported. | |
locate stylesheet module | After resolving against the base URI, the way in which the URI reference from the href 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 | 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 by 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 | 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 | 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, it is recommended that you 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 | 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 | 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 | 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 | 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 | The implementation uses the java.math.BigDecimal class, which supports nearly unlimited precision, except that 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 | 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. The 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 | The maximum
absolute values for the duration components are: |
|
year month duration | For the xdt:yearMonthDuration type: the maximum absolute value expressed as an integer number of months | XSLT 2.0 | The 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 | The 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 | 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 | 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
XPath 2.0 XQuery 1.0 |
Any URI is considered to be in the set of in-scope collations. Every URI that is used as a collation URI must be associated with a Java™ Collator at execution time. | |
implicit timezone | Implicit time zone | XSLT 2.0
XPath 2.0 XQuery 1.0 |
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 |
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 | 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. The default value 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 | If the override
attribute had the value of yes, stylesheet functions can override
the following: 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 | 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 | 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 | ||
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 that is used is implementation defined. The set of languages for which numbering is supported is implementation defined. If a language is requested that is not supported, the processor uses the language that it would use if the lang attribute were omitted. |
XSLT 2.0 | 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 | 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 | 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 by 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 | 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 | 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 | 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 that 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 | 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 | 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 that 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 | 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 | ||
defaults in date formatting functions | Default language, calendar, and country in the date-formatting functions if arguments are omitted or empty | XSLT 2.0 | ||
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 that the implementation does not recognize, the processor uses an implementation-defined language. |
XSLT 2.0 | 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 | The International Components for Unicode (ICU) website has a Locale Explorer that contains 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 | 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 | 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: |
|
set of system properties | Set of system properties | XSLT 2.0 | The processor
supports the following: |
|
xslmessage | Way in which an xsl:message instruction sends a message | XSLT 2.0 | 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 | 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 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 that the processor implements. | |
external objects | Way in which external objects are represented in the type system | XSLT 2.0 | Data objects whose values are of types that do not map to built-in types as described in Mapping 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 | 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:
|
|
URI restriction | Restrictions on form of absolute URI used in an href | XSLT 2.0 | 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, |
|
final result tree location | Location to which final result trees are serialized | XSLT 2.0 | 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 that is used can also be changed by calling the XDynamicContext.setBaseOutputURI() method. | |
default output encoding | Default value of the encoding attribute in xsl:output | XSLT 2.0 | The default output encoding is UTF-8. | |
byte-order-mark for UTF-8 | Byte-order-mark for UTF-8 | XSLT 2.0 | The default value 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 | No implementation-defined normalization forms are provided. | |
output version | Permitted and default value of the version attribute in xsl:output | XSLT 2.0 | 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 | 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 | The processor is schema aware as defined in Section 3.13 of the XSLT 2.0 specification. | |
namespace for additional error codes | Namespace that is used if additional error QNames are defined by the implementation | XSLT 2.0 | 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 | 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 | 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 | 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 | The processor
implements the following additional serialization parameters: |
|
additional normalization-form | Support for additional Unicode Normalization form | XSLT 2.0 and XQuery 1.0 Serialization | No implementation-defined normalization forms are provided. | |
option in encoding phase | Effect of an option that allows the encoding phase to be skipped so that the result of serialization is a stream of Unicode characters | XSLT 2.0 and XQuery 1.0 Serialization | No such option is provided by the processor. | |
cdata sec mechanism | Alternative mechanism requested by the user to create CDATA sections | SR | The processor does not provide an alternative mechanism for creating CDATA sections. | |
unicode version | Supported version of Unicode | XPath 2.0
XQuery 1.0 |
The processor supports the version of Unicode supported by the host JRE—namely, Unicode Standard Version 4.0 for Java 6 and Unicode Standard Version 6.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 | 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 | 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 that 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 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 that 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 | 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 that they support in these two situations. |
XQuery 1.0 and XPath 2.0 Functions and Operators | 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 | The 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 | 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 | 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 | 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 | The implementation uses the java.math.BigDecimal class, which supports nearly unlimited precision, except that 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
XPath 2.0 XQuery 1.0 |
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, that 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
XPath 2.0 XQuery 1.0 |
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 XQuery 1.0 | 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 | 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 | 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 | 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 | 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 | 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. You 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 | The settings of the serialization
parameters can be specified on an instance of the XOutputParameters
interface. |
|
unsuccessful external function call | The effect of an unsuccessful call to an external function | XQuery 1.0 | The processor will first report
an error to any instance of the XMessage handler
interface that is 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: |
|
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 | 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. |