Handling of source documents
When the source document is supplied as a pre-built tree (in any format), and Saxon strips whitespace
text nodes as requested by the stylesheet, the space stripping now takes account of any
attributes present in the tree. Specifically, whitespace text nodes are preserved if
is specified. This can be expensive, but is required for conformance. When supplying pre-built trees
as input (whether as DOM, JDOM, or XOM trees, or as native Saxon trees) it is best not to use
xsl:strip-space in the stylesheet.
When the source document is supplied as a DOM or JDOM tree, multiple adjacent text and CDATA nodes are now mapped to a single text node in the XPath model. If the XPath text node is passed to a Java extension function, the extension function sees the first node in the underlying sequence. This change has not yet been made for XOM trees.
Saxon accepts URIs of the form "document.xml#id" where "id" is the value of an attribute defined in the DTD
as being of type ID. It now also accepts such URIs where the fragment identifier is the value of an
Where a stylesheet is embedded in a source document, or a schema is embedded within a stylesheet, the base URI of the embedded document was previously taken as being the same as the base URI of the containing document. It is now taken as the base URI of the relevant element. This means that the xml:base attribute is taken into account.
In a previous release, following a change in the W3C specifications, Saxon was changed so
that DTD-based types such as ID and IDREF did not set the type annotation on the attribute node.
An unintended consequence of this change was that the idref() function stopped working when an
attribute was defined in the DTD as being of type IDREF or IDREFS. This has now been fixed. Doing so
required some changes to the data model. The is-id and is-idref properties defined in the W3C data model
are not reflected directly in the Saxon implementation, but the information is now available in a slightly
different way. The method
getTypeAnnotation() when applied to an attribute node may
now return a value that contains the fingerprint code for the type
xs:IDREFS together with a high bit (
that the type is DTD-derived rather than schema-derived. When this bit is set, the value should be treated
as being untyped atomic, but the type annotation returned indicates whether the is-id or is-idref properties
are present. This same change applies to the type code passed with attributes in the
Saxon-SA 8.5 allows an XML document to be saved on disk in a format referred to as a PTree. This is a binary format designed for speed of loading. A document in PTree format takes about the same amount of disk space as the original source XML, but takes about half as long to load into memory. The saving is greater when the document contains type information, because this is retained in the PTree without the need to revalidate.
Two new commands are available,
com.saxonica.ptree.PTreeReader to convert XML documents into PTrees and vice
A PTree can be supplied as the input to a transformation or query using the class
which implements the JAXP
A new command-line option is available on the commands
com.saxonica.Query. The option
-p causes a URIResolver to be used
that recognizes the file extension
.ptree as representing a Saxon PTree. This option
implicitly switches on the
-u option, meaning that the source file name is interpreted
as a URI. The
PTreeURIResolver, as well as recognising the
.ptree file extension, also
recognizes query parameters at the end of a URI. In particular it recognizes the parameters
validation=strip which control how a source
document is schema-validated. For example,
doc('source.xml?validation=lax') loads a source
document with lax validation. This option allows different validation to be applied to different source
documents loaded by a single query or transformation.
The result of a query or transformation can be serialized as a PTree by specifying
as the serialization
method. From the command line, use the parameter
The PTree format has been designed so that one Saxon release should normally be able to read PTree files created by an earlier release. It may not always be possible, however, to read PTrees created using a later Saxon release. The PTree is not dependent on any particular NamePool, and can be freely moved between different machines just as source XML can. It is a binary format, so there is no dependency on any particular character encoding or machine architecture. PTree files are not designed to be read or written directly by user applications, nor are they designed to provide an interchange format between Saxon and other products: the internal format is therefore not published.
When a PTree contains type information, the schema that defines those types must also be loaded. This doesn't happen automatically. At present, there is no way of storing a compiled schema on disk, so this will generally involve rebuilding the schema from its source representation. It is the user's responsibility to ensure that the loaded schema is consistent with the schema that was used to validate the original XML document.