Bug 6559 – [XPath] PI name test must require string literals that satisfy NCName rules

Bug 6559 - [XPath] PI name test must require string literals that satisfy NCName rules

Summary:

[XPath] PI name test must require string literals that satisfy NCName rules

Status:	RESOLVED REMIND

Product:	XPath / XQuery / XSLT
Component:	XPath 2.0
Version:	Recommendation
Platform:	PC Windows NT

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Jonathan Robie
QA Contact:	Mailing list for public feedback on specs from XSL and XML Query WGs

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2009-02-11 17:31 UTC by Tim Mills
Modified:	2009-03-18 10:09 UTC (History)
CC List:	3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Tim Mills 2009-02-11 17:31:04 UTC

Bug 5351 closed following the resolution of the bug with the text

"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."

To resolve Bug 6238, could you please clarify whether

"...PI name test cannot be converted to an NCName."

means that

processing-instruction("b ")

raises XPTY0004, or is equivalent to 

processing-instruction("b")

because "b " can be converted to an NCName using xs:NCName("b ").

It would seem reasonable that the normaliztion rules for constructed processing
instructions would be updated along the lines of:

[processing-instruction StringLiteral{ Expr }]Expr
==
processing-instruction { xs:NCName(StringLiteral) }{
fs:item-sequence-to-untypedAtomic-PI(( [Expr]Expr)) }

Comment 1 Michael Dyck 2009-02-11 21:20:06 UTC

> It would seem reasonable that the normaliztion rules for constructed
> processing instructions would be updated along the lines of:
> 
> [processing-instruction StringLiteral{ Expr }]Expr
> ==
> processing-instruction { xs:NCName(StringLiteral) }{
> fs:item-sequence-to-untypedAtomic-PI(( [Expr]Expr)) }

So far, the discussion (in the referenced bugs) has been about PITest.
Are you sure you want to bring in CompPIConstructor?

Also, note that there's no such syntax as
    processing-instruction StringLiteral { Expr }
You're maybe thinking of
    processing-instruction { StringLiteral } { Expr }

Comment 2 Tim Mills 2009-02-12 10:34:53 UTC

Sorry, yes - I had meant the node test.

That said, normalizing the string literal of a CompPIConstructor with xs:NCName
doesn't seem like too bad an idea...

Comment 3 Michael Kay 2009-02-12 17:34:44 UTC

Changed component to XPath.

Comment 4 Michael Kay 2009-02-12 17:41:36 UTC

Thed XSL WG had no strong views on whether whitespace should be allowed, but
decided on balance that it should - i.e. it should be the same rules as the
xs:NCName() constructor function.

Comment 5 Jonathan Robie 2009-02-23 17:14:21 UTC

At today's F2F, the WG agreed to adopt this.

We will check the target to make sure it is a valid NCName. Whitespace is
allowed, we use whitespace normalization before testing.

Comment 6 Jonathan Robie 2009-02-23 19:10:11 UTC

*** Bug 5355 has been marked as a duplicate of this bug. ***

Comment 7 Jonathan Robie 2009-02-23 19:12:52 UTC

*** Bug 5351 has been marked as a duplicate of this bug. ***

Comment 8 Jonathan Robie 2009-03-18 09:29:34 UTC

This fixes the problem:

processing-instruction(N) matches any processing-instruction node whose name
(called its "PITarget" in XML) is equal to fn:normalize-space(N), which must be
an NCName.

It can be made less awkward by referring to the target property from our data
model:

processing-instruction(N) matches any processing-instruction node whose target
property is equal to fn:normalize-space(N), which must be an NCName.

Comment 9 Michael Kay 2009-03-18 10:09:13 UTC

>which must be an NCName

The result of normalize-space() will never be an NCName. You mean "which must
be castable as an NCName" or "which must have the lexical form of an NCName".