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 6238 - CVS: K2-NameTest-22
Summary: CVS: K2-NameTest-22
Status: CLOSED FIXED
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Frans Englich
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-19 17:09 UTC by Tim Mills
Modified: 2010-03-16 14:38 UTC (History)
3 users (show)

See Also:


Attachments

Description Tim Mills 2008-11-19 17:09:45 UTC
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 "))
Comment 1 Frans Englich 2008-11-28 09:23:36 UTC
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.
Comment 2 Tim Mills 2008-11-28 09:48:55 UTC
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.
Comment 3 Andrew Eisenberg 2009-03-16 20:06:19 UTC
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."

Comment 4 Frans Englich 2009-10-13 13:11:27 UTC
A fix has been attempted in CVS. Test expects output now.
Comment 5 Tim Mills 2009-10-13 15:58:34 UTC
The expected result appears to be:

"<doc>false</doc>"

but should be:

"<doc>true</doc>"
Comment 6 Frans Englich 2009-10-14 13:24:43 UTC
Right, new fix attempted.
Comment 7 Tim Mills 2009-10-14 14:18:14 UTC
Thanks.
Comment 8 Tim Mills 2009-12-17 12:23:10 UTC
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"))
Comment 9 Frans Englich 2010-03-15 12:38:13 UTC
Agreed, baseline is false in CVS.
Comment 10 Tim Mills 2010-03-16 14:38:46 UTC
Thanks.