This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

run-time errors in XSLT



I've been scanning the XSLT spec for the word "error". In many places, it
says something like "implementations may either signal the error or
ignore..." Up until now, I've always thought discretion should not have
been given, and that the processor should just throw an error. The best
example of this is when two template rules match the same thing with the
same priority in the same mode; the XSLT processor may either signal the
error or just pick the last one in the stylesheet (lame). But now, I'm
starting to wonder whether discretion was given in certain cases so that
an implementation could be guaranteed to never have a run-time error. Most
of the errors I see mentioned are ones that could be caught at
compile-time. But I am noticing a few run-time possibilities. For example,
the name attribute of xsl:element and xsl:attribute is interpreted as an
attribute value template, which means that a run-time error could be
thrown.

What the spec says for xsl:attribute:

<quote>
The name attribute is interpreted as an attribute value template. It is an
error if the string that results from instantiating the attribute value
template is not a QName or is the string xmlns. An XSLT processor may
signal the error; if it does not signal the error, it must recover by not
adding the attribute to the result tree. 
</quote>

Okay, so you could avoid a run-time error by just not adding the
attribute. The rules for xsl:element are a bit funnier:

<quote>
An XSLT processor may signal the error; if it
does not signal the error, then it must recover by making the the result
of instantiating the xsl:element element be the sequence of nodes created
by instantiating the content of the xsl:element element, excluding any
initial attribute nodes.
</quote>

Another possibility for a run-time error (I think):

<quote>Adding an attribute to a node that is not an element;
implementations may either signal the error or ignore the
attribute.</quote>

Instantiating comments and processing instructions in the result tree via
xsl:comment and xsl:processing-instruction can also result in all kinds of
run-time errors. But for every error, the spec allows for an escape
mechanism. For an example of these creative escape routes:

<quote>
It is an error if the result of instantiating the content of the
xsl:comment contains the string -- or ends with -. An XSLT processor may
signal the error; if it does not signal the error, it must recover by
inserting a space after any occurrence of - that is followed by another -
or that ends the comment.
</quote>

Regarding the document() function, the XSLT spec is pretty clear and 
foresighted. In fact, it says that a root node is returned only "if the
URI reference does not contain a fragment identifier." 

It then adds:

<quote>
If the URI reference does contain a fragment identifier, the
function returns a node-set containing the nodes in the tree identified by
the fragment identifier of the URI reference. 
</quote>

It recognizes that there are a number of possible run-time errors here,
and even enumerates some possibilities, such as the fragment identifier
selecting a "range" of characters, which cannot be represented by an XSLT
node-set. (It's clear he's referring to XPointer's extensions to XPath.)
For all kinds of errors, including problems with retrieving the resource
over the network, "the XSLT processor may signal the error; if it does not
signal the error, it must recover by returning an empty node-set."

So... it seems that the spec goes out of its way to let implementors build
an XSLT processor that's guaranteed to never throw a run-time error. It
seems that way at least...

But wait, what about this one (regarding the encoding attribute of
xsl:output):

<quote>
It is possible that the result tree will contain a character that cannot
be represented in the encoding that the XSLT processor is using for
output. In this case, if the character occurs in a context where XML
recognizes character references (i.e. in the value of an attribute node or
text node), then the character should be output as a character reference;
otherwise (for example if the character occurs in the name of an element)
the XSLT processor should signal an error.
</quote>

I tend to view this one as a lesser status type of error, because it
regards one of those serialization hooks rather than possible errors
within the realm of pure tree transformations.

I want to see an annotated XSLT spec!! I want to know what
James, et al. were thinking.

The only general words I see on errors is in the brief "Conformance"
section. They are:

<quote>
A conforming XSLT processor must signal any errors except for those that
this document specifically allows an XSLT processor not to signal. A
conforming XSLT processor may but need not recover from any errors that it
signals.
</quote>

But... some errors that can be recognized at compile-time clearly should
not be "recovered from". Maybe to "recover from" an error implies that the
error is by definition a run-time error...  But there is no distinction
in the spec between run-time and compile-time. Thus, there's definitely a
subtext here, and there's not enough information about what's meant in
that last quote.

Anyone have any insight here?

Evan Lenz
XYZFind Corp.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]