Errors

Mike Kay

>  <xsl:variable name="temp">data/row</xsl:variable>
> 
> the output says "cannot convert to 
> node-set".  

You have assigned the variable temp to the string "data/row" (actually to a result tree fragment containing this string, but that's academic in this case), not to the result of the XPath expression data/row. You have then tried to use this string in a context where a nodeset is required. What you meant to say was:

<xsl:variable name="temp" select="data/row"/>

            

Mike Brown

If the xsl namespace is incorrect, then there are no elements in the stylesheet associated with the one correct XSLT namespace. Elements that are in a namespace that is not recognized by the XSL processor are interpreted to be literal result elements. The built-in processing rules prescribed by the spec are applied. Should be xmlns:xsl="http://www.w3.org/1999/XSL/Transform" This error shows up if any part is wrong

Paul Grosso

 Kay Michael wrote:
>> "XSL Warning:Specificity conflicts found:  
>> "* | text() | @*", text()|@*" Last found in stylesheet
>> will be used.
>
>The XSLT spec says that it's an error to have two template rules with the
>same priority and precedence and mode that match the same node; and that the
>processor has the option of reporting this error or recovering from it using
>the last one found in the stylesheet.
>
>Xalan, I believe, does both: it reports the problem as a warning and then
>takes the recovery action. This seems a sensible strategy and in my view
>it's within the conformance rules, even though it doesn't seem to be quite
>what the writers of the spec had in mind.

Different writers of the spec had different ideas, but I do think Xalan's behavior is quite consistent with what we had in mind.

Some of us wanted draconian error handling and wanted such an error to cause the XSLT processor to stop emitting a result tree, but others wanted to be able to keep plugging along. At the time, most of us felt that anything but an HTML-like browser (whose idea is to display something no matter what happens) should probably give some kind of (perhaps user-suppressable) warning in the case of specificity conflict. Some of us were quite concerned that defining a recovery in terms of stylesheet template order would end up effectively defining stylesheet order to be the specificity rule most people used, and this was something many of us felt would be a bad idea. For good or evil, this has, in fact, happened for the most part.

But users should be aware that relying on stylesheet order is not appropriate according to XSLT, and an XSLT stylesheet editor, for example, is perfectly within its rights to reorder one's stylesheet and to refuse to allow two templates with the same specificity. The fact that some tools give specificity conflict warnings should help enforce this notion, and I applaud any tools that do so.