OASIS XSLT/XPath Conformance

OASIS has produced a test system for XSLT processors. Since XSLT depends so heavily on XPath, it also serves to test XPath expressions.

This test suite has been developed as an instance of a test regime within the OASIS generic test framework.

The XSLT discretionary items in the summary are grouped by their status accoding the values listed here.

controlling test selection in the current version

proposed for testing in the next deliverable version

proposed to postpone

acknowledged as discretionary but considered not testable

out of scope for conformance testing

Each XSLT test case must be categorized as to the nature of the test according to the categories listed here.

This allows users of the test cases to only address a subset of the tests by their nature.

stylesheet/transform, namespaces, import, include

treatment of source XML, text + whitespace, entities

matching, call named, priority

creation of nodes in result

sort, for-each, conditionals, variables, keys

functions and instructions related to extendability

output, message

axes, node tests, predicates

operators, type conversion

all XPath functions

all other XPath not covered above

would fit into more than one category

Both the discretionary and test case documents make citations into Recommendations.

These are the allowed methods of citing specifications as configured for the regime.

section heading in rendered Rec, must have number at start

HTML-style anchor

id from document, optionally followed by XPath to qualify further

These are the allowed Recommendations to be cited by the descretionary document or test cases.

numbered chapter/section/subsection

from available id

available anchors

numbered chapter/section

from available id

available anchors

numbered chapter

from available id

available anchors

It is assumed that multiple editions of XSLT errata are cumulative, thus later editions subsume the errata of earlier editions.

These are the "Known errors as of [date]" sections

Erratum are numbered, starting with E1, and matching anchors exist for each.

It is assumed that multiple editions of XPath errata are cumulative, thus later editions subsume the errata of earlier editions.

Has sections parallel to sections of base document.

Whatever anchors we can find....

Areas that are not discretionary but may be cited by a test case as being vague.

The largest number that a test case may safely assume can be formatted as a Roman numeral by xsl:number.

The erratum turned this into a discretionary item: It is an error if the number is NaN, infinite or less than 0.5; an XSLT processor may signal the error; if it does not signal the error, it must recover by converting the number to a string as if by a call to the string function and inserting the resulting string into the result tree.

Prior to the erratum, there was no specification for how xsl:number level="any" should deal with an empty node-set.

The erratum made this similar to level="single" by saying: If there are no matching nodes, it constructs an empty list.

If the test makes this empty-list choice, it may also be marked for an errata-add of 2000-12-12 on XSLT Version 1.0.

The scenarios describe the testing methodologies (operations) possibile for a single test. Every test must point to one of the operations described.

2 principal inputs, one principal output

specify both a principal-data and principal-stylesheet type of input-file

input is XML data with embedded styling (principal-data only)

like standard but also has parameters passed in

2 principal inputs, but NOT expected to generate output

like standard but something interactive happens

Use this classification when human examination of console or output is needed.

Principal files must be name only (with filetype extension/tag included), not a path.

Supplemental files may have relative paths with / separators

Constraint: names for output-files, both principal and supplemental, must be designed so that all test cases sharing a submitter/file-path directory may be run in one batch with no naming conflicts.

the XML data to be processed, generally called the "source tree" in the Recommendation, specified as an argument when invoking the XSLT processor

the stylesheet to be specified as an argument when invoking the XSLT processor

for output only: transformation result named at invocation

for input only: extra file read by document() or similar

for input only: extra stylesheet read by xsl:import or similar

for input only: file specifying how to set external parameters

for output only: extra file from console log, xsl:document, etc.

Most output files can be compared mechanically, but the 'manual' is provided when this is not possible.

XML in a file

HTML in a file

text in a file

the output cannot be automatically verified

Use this for generate-id when a human must verify that the generated id meets constraints, and for all the vendor-specific strings returned by system-property.

the output should not have been generated

Not all XSLT processors support all data types for parameters

XPath string data type

XPath number data type

XPath boolean data type