1
votes

I have this source xml:

 <cip>
   <data>
      <typo>
         <articles>
            <article id="BM017106--">
               <lang>Lang Text(de-AT) -- BM017106--:6</lang>
            </article>
            <article id="XC01010101">
               <lang>H07V-U (Ye) 1,5mm² schwarz, PVC Aderleitung eindrähtig</lang>
            </article>
         </articles>
      </typo>
   </data>
</cip>

And following xslt:

 <xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

   <xsl:template match="/">
      <xsl:message select="cip/data/typo/articles/article[1]/@id"/>
   </xsl:template>

</xsl:stylesheet>

When I transform this with Saxon saxon9ee.jar all works fine. When I try to transform this with saxon-ee-10.3.jar, I got: Error XTDE0420, Cannot create an attribute node (id) whose parent is a document node. Have anyone an idea what's going wrong?

1
Which result exactly do you get with Saxon 9 when all is "fine"? Just that message with the attribute name and/or value? Perhaps for Saxon 10, as a workaround, output e.g. cip/data/typo/articles/article[1]/@id!(local-name() || '=' || .). - Martin Honnen
There is a very old bug report saxonica.plan.io/issues/950 saying that Saxon 9 tried to be user-friendly by not raising that error, not sure what has changed in 10.3. - Martin Honnen
With Saxon 9 I get: <?attribute name="id" value="BM017106--"?> - user2728103
The test case github.com/w3c/xslt30-test/blob/master/tests/insn/message/… seems to check this, no idea why the problem did not turn up in Saxon release tests, it seems 10.0 has the behaviour of recovering by outputting the attribute node as processing instruction while 10.1 is the first Saxon release to raise XTDE0420. - Martin Honnen

1 Answers

1
votes

The XSLT 3.0 specification says (in §23.1):

If the xsl:message instruction contains a sequence constructor, then the sequence obtained by evaluating this sequence constructor is used to construct the content of the new document node, as described in 5.7.1 Constructing Complex Content.

And 5.7.1 says that attempting to attach an attribute node to a document node is an error.

§23.1 goes on to say:

Any dynamic error that occurs while evaluating the select expression or the contained sequence constructor, and any serialization error that occurs while processing the result, does not cause the transformation to fail; at worst, it means that no message is output, or that the only message that is output is one that relates to the error that occurred.

and this is what Saxon does: it outputs the error message as the content of the xsl:message instruction, and the transformation continues on its way.

The Note that immediately follows describes this very situation, where xsl:message attempts to output an attribute node. But the Note is incorrect in stating that it is implementation-defined whether or not they are signaled to the user and whether they cause termination of the transformation -- the normative text is clear that the error is never fatal.

So Saxon is behaving in a way that is consistent with the specification, although arguably one could do better, for example by serializing the value passed to xsl:message using the adaptive serialization method.

I'm not sure why it changed between releases.