This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I have been testing our XPath 2.0 implementation using the XQTS test suite (using those tests marked with is-XPath2='true'). I'm probably mistaken, but the queries Literals056: "&" and Literals057: """ give different results depending on whether XQuery 1.0 or XPath 2.0 is used because of the differences in the StringLiteral grammar. This contradicts the paragraph: "XQuery Version 1.0 is an extension of XPath Version 2.0. Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages." in the XQuery 1.0 specification.
Yes, the statement is incorrect in this respect. XPath is designed for embedding in XML documents and therefore leaves the XML parser to expand the entity references before XPath parsing starts.
(In reply to comment #1) > Yes, the statement is incorrect in this respect. > > XPath is designed for embedding in XML documents and therefore leaves the XML > parser to expand the entity references before XPath parsing starts. I don't think the statement is incorrect - XPath can be embedded in many different contexts, not just XML, and this is just one example in which some kind of processing is done in a given context to produce an XPath expression. Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages. That's true. If you embed your XPath or XQuery expression in an XML document and use XML entities in this manner, the expression is whatever is handed off to the XQuery or XPath processor, not the text you see in the XML document. I do not see a need to change the documents here.
The original comment is correct: if for example you execute the XPath expression string-length("&") from a Java application using the JAXP API, you will get the result 5, whereas if you execute the same expression using an XQuery processor using the XQJ API, you will get the result 1. Of course if you write in XSLT <xsl:value-of select='string-length("&")'/> you will get the answer 1. But that's because the XPath expression you are evaluating is string-length("&") which is not even legal as an XQuery expression.
If an XQuery processor receives the query "&" the result is & If an XPath 2.0 processor receives the query "&" _after_ any decoding due to it being embedded in some other language (e.g. XSLT 2.0) the result is & "Any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages." Here "&" is an expression that is syntactically valid and executes successfully. It will not, however, return the same result.
Clearly, I'm wrong and the original commenter is right. Sorry for the confusion.
I propose to fix this with the following text in XQuery 1.1: <quote="XQuery 1.1"> XQuery Version 1.1 is an extension of XPath Version 2.1. In general, any expression that is syntactically valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in both languages. There are a few exceptions to this rule: * Because XQuery expands character entity references and XPath does not, expressions containing character entitities produce different results in the two languages. For instance, the value of the string literal "&" is & in XQuery, and & in XPath. (XPath is often embedded in other languages, which may expand character entitities before the XPath expression is evaluated.) * The namespace axis, which was deprecated in XPath 2.0, is not supported in XQuery. * If XPath 1.0 compatibility mode is enabled, XPath behaves differently from XQuery in a number of ways, which are discussed in [XPath 1.0]. </quote> In XPath 2.1, the last bullet point is replaced with the following: <quote="XPath 2.1"> * If XPath 1.0 compatibility mode is enabled, XPath behaves differently from XQuery in a number of ways, which are noted throughout this document, and listed in "I.2 Incompatibilities when Compatibility Mode is false". </quote> I am marking this as fixed, feel free to reopen if I got this wrong.
Thanks.
(In reply to comment #6) > * Because XQuery expands character entity references and XPath does not, > expressions containing character entitities produce different results in the > two languages. For instance, the value of the string literal "&" is & in > XQuery, and & in XPath. perhaps the & got mangled in transit, but the above appears wrong, The string literal given, "&" is a syntax error in Xquery and the string of length 1 containing an ampersand in xpath. But it doesn't contain an entity reference so isn't an example of the first sentence. I think the intended example is the string literal "&" is "&" in Xquery and "&" in Xpath. Other minor comment: String literals contain entity references (not entities) (also typo: entitities --> entities ) David
(In reply to comment #8) > (In reply to comment #6) > > > * Because XQuery expands character entity references and XPath does not, > > expressions containing character entitities produce different results in the > > two languages. For instance, the value of the string literal "&" is & in > > XQuery, and & in XPath. > > perhaps the & got mangled in transit, but the above appears wrong, > > > The string literal given, "&" is a syntax error in Xquery and the string of > length 1 containing an ampersand in xpath. But it doesn't contain an entity > reference so isn't an example of the first sentence. I think the intended > example is > > the string literal "&" is "&" in Xquery and "&" in Xpath. Yes, the & got mangled in transit. I didn't know BZ did that! > Other minor comment: > > String literals contain entity references (not entities) > > (also typo: entitities --> entities ) Oooops .... nice catch!
The constructs affected are not "character entities" or "character entity references". In XML they are "character references" and "entity references"; in XQuery they are "character references" and "predefined entity references".
(In reply to comment #10) > The constructs affected are not "character entities" or "character entity > references". In XML they are "character references" and "entity references"; in > XQuery they are "character references" and "predefined entity references". Thanks - fixed that.