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 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)) }
> 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 }
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...
Changed component to XPath.
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.
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.
*** Bug 5355 has been marked as a duplicate of this bug. ***
*** Bug 5351 has been marked as a duplicate of this bug. ***
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.
>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".