Subject: [xsl] run-time errors in XSLT From: Evan Lenz <elenz@xxxxxxxxxxx> Date: Sun, 11 Feb 2001 00:38:30 -0800 (PST) |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments, Kaganovich, Yevgeniy | Thread | Re: [xsl] run-time errors in XSLT, David_Marston |
Re: [xsl] XSLT 1.1 comments, Evan Lenz | Date | Re: [xsl] XSLT 1.1 comments, Daniel Veillard |
Month |