This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This query, which tests the resolution of Bug 5351, incorrectly expects an error. Quoting Bug 5351: "The name test shown in this bug report will always result in a dynamic error. In its teleconference on 2008-01-08, the WG decided (because the error, caused by a string literal, can be caught statically) to make it a type error (XPTY0004) if the string literal of a PI name test cannot be converted to an NCName." Here, the string literal can be converted to a valid NCName using the constructor xs:NCName('b '). (:*******************************************************:) (: Test: K2-NameTest-22 :) (: Written by: Frans Englich :) (: Date: 2007-11-22T11:31:21+01:00 :) (: Purpose: A processing-instruction() with an invalid NCName in a string litera l. :) (:*******************************************************:) empty(let $e := <a b ="content"><?b asd?><b/></a> return $e/processing-instruction("b "))
Could we back this up with spec references? I fail to find some piece of text which says "The string literal appearing inside the node test processing-instruction() is treated as passed to the xs:NCName constructor function." A piece of functionality that raise XPTY0004, doesn't equal that the code uses casting, as far as I know.
I quoted the resolution of the bug. I'm not sure whether this has made it into the erratum yet. I've requested clarification under Bug 5351.
The resolution of Bug #5351 is reflected in erratum XQ.E12 (http://www.w3.org/XML/2007/qt-errata/xquery-errata.html#E12). This erratum adds the following text in 2.5.4.2 Matching an ItemType and an Item: "If the specified PITarget is not a syntactically valid NCName, a type error is raised [err:XPTY0004]." The WGs also resolved Bug #6559 recently, saying: "We will check the target to make sure it is a valid NCName. Whitespace is allowed, we use whitespace normalization before testing."
A fix has been attempted in CVS. Test expects output now.
The expected result appears to be: "<doc>false</doc>" but should be: "<doc>true</doc>"
Right, new fix attempted.
Thanks.
I made a mistake in Comment #5. The expected result of this test should be false, because the query is equivalent to empty(let $e := <a b ="content"><?b asd?><b/></a> return $e/processing-instruction("b"))
Agreed, baseline is false in CVS.