6559 2009-02-11 17:31:04 +0000 [XPath] PI name test must require string literals that satisfy NCName rules 2009-03-18 10:09:13 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 2.0 Recommendation PC Windows NT RESOLVED REMIND P2 normal --- 1 tim jonathan.robie jim.melton jmdyck mike public-qt-comments oldest_to_newest 23648 0 tim 2009-02-11 17:31:04 +0000 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)) } 23657 1 jmdyck 2009-02-11 21:20:06 +0000 > 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 } 23667 2 tim 2009-02-12 10:34:53 +0000 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... 23681 3 mike 2009-02-12 17:34:44 +0000 Changed component to XPath. 23682 4 mike 2009-02-12 17:41:36 +0000 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. 23880 5 jonathan.robie 2009-02-23 17:14:21 +0000 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. 23885 6 jonathan.robie 2009-02-23 19:10:11 +0000 *** Bug 5355 has been marked as a duplicate of this bug. *** 23887 7 jonathan.robie 2009-02-23 19:12:52 +0000 *** Bug 5351 has been marked as a duplicate of this bug. *** 24309 8 jonathan.robie 2009-03-18 09:29:34 +0000 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. 24310 9 mike 2009-03-18 10:09:13 +0000 >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".