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
It is assumed that multiple editions of XSLT errata are cumulative, thus later editions subsume the errata of earlier editions.
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.
It is assumed that multiple editions of XPath errata are cumulative, thus later editions subsume the errata of earlier editions.
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.
Both the discretionary and test case documents make citations into Recommendations.
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
$Date: 2005/04/06 20:55:17 $(UTC)