This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5269 - [XQX] No way to represent K2-NameTest-21 in XQueryX
Summary: [XQX] No way to represent K2-NameTest-21 in XQueryX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2007-11-15 16:40 UTC by Oliver Hallam
Modified: 2008-02-18 11:09 UTC (History)
0 users

See Also:


Description Oliver Hallam 2007-11-15 16:40:36 UTC
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
Comment 1 Michael Kay 2007-11-15 16:54:22 UTC
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.
Comment 2 David Carlisle 2007-11-15 17:10:29 UTC
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...

Comment 3 Jim Melton 2007-11-17 00:24:44 UTC
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. 
Comment 4 Jim Melton 2008-01-08 18:16:24 UTC
In its teleconference on 2008-01-08, the Working Group agreed with the conclusion in 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.