This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The test XQueryX/Construct/ComputeCon/ComputeConAttr/K2-ComputeConAttr-35.xqx is a bit wrong. Libxslt translates it into wrong XQuery, because xqx:computedTextConstructor and xqx:computedAttributeConstructor are in the wrong order, so it generates the text constructor before the attribute constructor.
The original XQuery version of the query is: <elem><![CDATA[]]>{attribute name {"content"}}<alem/> </elem> I believe the XQueryX version of the query is equivalent. That is, the xqueryx.xsl stylesheet translates it back to: <elem> { text {"" } } { attribute name {"content" } }<alem></alem></elem> which has the same behaviour as the original query. It's true that the underlying semantics are slightly different. With respect to section 3.7.1.3 (XQuery 1.0) or section 3.8.1.3 (XQuery 3.0), <![CDATA[]> supplies no 'literal characters', and therefore does not contribute a text node to the content sequence [points 1b and 1c], whereas { text {"" } } does contribute a text node to the content sequence [point 1e], which is then removed [point 3: "any text node whose content is a zero-length string is deleted from the content sequence"]. But either way, the outcome is the same: by the time we get to point 4, there is no text node before the attribute node in the content sequence, so err:XQTY0024 is not raised. That's basically the point of the test.
You are right, it's our bug. Thank you.
Oh, by the way: if your implementation supports Static Type Analysis as defined in the Formal Semantics, then it *would* raise err:XQTY0024 (basically because the analysis isn't smart enough to know that the text node will be removed). But it would do so for both the original and round-tripped queries, so the XQuery and XQueryX versions are still equivalent.