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-of
is replaced byvalidation="preserve|strip"
. The default is "preserve". (The other options,strict
andlax
, are not implemented.) -
The
[xsl:]type-annotation
attribute 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:integer
orxs:date
. -
The
type-information
attribute ofxsl:variable
andxsl:param
is 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 Receiver
s, 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)
.