XSLT 2.0 implementation
The required="yes|no" attribute on xsl:param is implemented. Currently,
failure to supply a required parameter is a dynamic error, it is never detected statically.
{ntmp01, ntmp901err}
The xsl:next-match instruction is implemented. {cnfr24-27}
The error that occurs when the name attribute of xsl:element or
xsl:attribute contains an undeclared prefix (in the absence of the namespace
attribute) is now recoverable. This brings it into line with the handling of other errors in this
value. Note however that if the name is known statically then the error is reported at compile time
and is fatal.
The error that occurs when a namespace or attribute node is written using xsl:copy-of,
when there is no open element start tag, is now recoverable. This brings it into line with other
instructions such as xsl:attribute and xsl:copy. {copy62}
Implemented the new facility to allow construction of sequences in XSLT, when a variable
binding element has content and an as attribute.
Added the as attribute to xsl:function. {func20}
Implemented the xsl:sequence instruction, including the as attribute
which checks the type of the returned sequence and performs any necessary (and permitted) conversions. {seqNNN}
The xsl:result element is withdrawn. It can always be replaced by xsl:sequence.
The as attribute, which denotes the return type of the function, should preferably be moved to the
xsl:function element.
Parentless attribute, text, comment, processing-instruction, and namespace nodes are implemented.
They are probably a little fragile - some operations on such nodes (e.g. xsl:number,
xsl:apply-templates)
have not been tested. The new rules for match patterns with parentless nodes have not been implemented:
it's probably best to avoid using apply-templates on such nodes for the moment. {seqNNN}
Some instructions, e.g. xsl:value-of, incorrectly generate multiple text nodes,
some other instructions may pre-merge the text nodes.
Handling of document nodes within the constructed sequence is probably not yet correct.
The separator attribute of xsl:copy-of is withdrawn.
Revised syntax for validating result trees
The 2 May 2003 WD changes the syntax for attaching type annotations to nodes in a result tree. These facilities are only partially implemented in Saxon, and no new functionality is provided in this release, but the existing functionality has been converted to use the new syntax. Specifically:
-
The attribute
copy-type-annotations="yes|no"onxsl:copy-ofis replaced byvalidation="preserve|strip". The default is "preserve". (The other options,strictandlax, are not implemented.) -
The
[xsl:]type-annotationattribute ofxsl:element,xsl:attribute, and literal result elements is renamed[xsl:]type; it is still restricted to be a built-in simple type such asxs:integerorxs:date. -
The
type-informationattribute ofxsl:variableandxsl:paramis withdrawn.
In backwards compatibility mode, the November 2002 XPath 2.0 draft specification currently says (if you read it carefully) that for a function expecting an integer, the supplied value should be cast to a double. Saxon 7.4 does this and it fails. This is a bug in the spec, which is fixed in the May 2003 draft; it has been fixed in Saxon 7.5. {type036, type037}
The changes that started in 7.3 to replace the Emitter class with the Receiver
interface have now been completed. The only remaining classes that are Emitters are those that actually
write to a Writer or OutputStream - that is, the XMLEmitter,
HTMLEmitter, etc. All other classes in the
pipeline are now Receivers, many of them being defined as subclasses of ProxyReceiver which
is essentially a filter in the pipeline. The output properties are now notified to each serialization
filter as it is created, rather than being passed down the pipeline.
Identity transformations now copy the source to the result via the Receiver interface, not via SAX2
events as before. Two new classes DocumentSender and DOMSender
have been introduced to generate Receiver
events from a Saxon DocumentInfo or a DOM Document respectively.
The saxon:doctype extension has been completely rewritten. It no longer uses a custom
serializer, but instead generates the DTD within the code of the instruction itself, outputting the
result using the standard serializer with disable-output-escaping. There may be changes in edge cases,
for example the handling of namespaces within the expansion text of entities.
The standard URIResolver has been changed to use the JDK 1.4 class java.net.URI
in place of the old java.net.URL. This gives stricter adherence to the rules for URI handling
and appears to handle a wider range of URI formats. One effect is that (for reasons that I do not fully
understand) it is now possible to use Microsoft UNC filenames of the form \\server\share\dir\file.xml
from the Saxon command line. Another effect of the change is that URIs are checked more rigorously: for
example, a URI that uses backslashes instead of forward slashes is now rejected.
The OutputURIResolver is now used for resolving the principal output document (including the filename
given on the command line) as well as secondary result documents. This eliminates a lot of duplicated code.
The standard OutputURIResolver has
been enhanced to be capable of supporting URI schemes other than the file scheme; however, I haven't
identified any schemes that support output using the standard JDK 1.4 libraries. The file URI scheme
now maps URIs to filenames using standard methods provided in JDK 1.4, rather than through ad-hoc
parsing of the URI: this means that invalid URIs such as file:/c:\temp.xml will be rejected
at this release even though they were accepted by earlier releases.
These changes can cause difficulties dealing with filenames that contain spaces. For example, the JAXP
classes StreamSource and StreamResult, when given a File as input, do not apply URI escaping to the
filename. This means that the "System Id" they contain is not guaranteed to be a valid URI, for example
it may contain spaces. Saxon may therefore report an Illegal URI when using the system identifier as
the base for resolving other URIs. To prevent this problem, given a file java.io.File fname,
use the constructor new StreamResult(fname.toURI().toString()) rather than
new StreamResult(fname).