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 XQTS test K2-NameTest-21 is as follows: empty(let $e := <a b ="content"><?b asd?><b/></a> return $e/processing-instruction("123ncname")) This is a valid (although not very useful) query. However, there is no way to represent this in XQueryX. The schema requires an xs:NCName as the processing instruction target in an <xqx:piTest> element. Perhaps this should be relaxed to an xs:string to allow compatibility with the above query? A similar problem occurs in K2-NameTest-23
XPath 1.0 failed to impose the obvious rule that the string literal must be a valid name. On reflection, we should probably have corrected that mistake in XPath 2.0. I think it's good that we've corrected it in XQueryX, where there is no possible argument based on backwards compatibility.
It's actually surprising that it is a valid query, if you use the CompPIConstructor with "123ncname" you get a dynamic error. However it's probably too late to say that it should be a static error to do this on PITest, although it's a bit odd to insist that only a string literal can be used, but then not to mandate any static checking of that literal. If Xquery can't be changed, then rather than just duplicate the problem into xqueryx I'd just say that as processing-instruction("123ncname") is clearly equivalent to () (or processing-instruction()[false()] if you prefer) then the Xquery expressible in XqueryX so long as the translation from xquery to xqueryx does "the right thing". Personally I'd have preferred to have had a specified equivalence between Xquery and XqueryX so one could actually decide whether a given XqueryX was "equivalent" to an Xquery one, but that is an argument I lost in this forum ages ago... David
I have to agree with Mike Kay. Although the query you cited is syntactically valid XQuery, it is not really valid XQuery as it is guaranteed to produce a dynamic error. (And, by the way, a conforming processor might be able to detect that the query will fail at runtime because of the obviously inappropriate literal string value, in which case that processor can raise the dynamic error at "analysis" time.) I see no reason to modify the XQueryX specification specifically to allow invalid queries to be represented.
In its teleconference on 2008-01-08, the Working Group agreed with the conclusion in http://www.w3.org/Bugs/Public/show_bug.cgi?id=5269#c2 that the error actually lies in the XQuery spec and not in the XQueryX spec. As a result, I am marking this bug RESOLVED INVALID, but opening a new XQuery bug reflecting that decision. Please mark this bug CLOSED at your earliest convenience.