This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We are looking at ForExprType060 and ForExprType061 in XQTS which are for $test as processing-instruction("filesystem") in ($input-context//fs:Folder)[1]//processing-instruction() return $test and for $test as processing-instruction("unknown") in ($input-context//fs:Folder)[1]//processing-instruction() return $test one if which is meant to throw a type exception, the other not, as all processing instructions nodes are <?filesystem?>. But I don't believe the formal semantics describe this behaviour. The normalization rules in 3.5.4 state [processing-instruction(StringLiteral)]sequencetype == processing-instruction? Static typing in 4.8.2: statEnv |- Expr1 : Type1 Type0 = [ SequenceType ]sequencetype statEnv |- prime(Type1) <: Type0 statEnv |- VarName1 of var expands to Variable1 statEnv + varType(Variable1 => Type0) |- Expr2 : Type2 statEnv |- for $VarName1 as SequenceType in Expr1 return Expr2 : Type2 ยท quantifier(Type1) passes for the above expressions as the types are Type0 and prime(Type1) are both processing-instruction For dynamic evaluation 8.3.1 Matches states statEnv |- processing-instruction NCName { String } matches processing-instruction and statEnv |- Value matches (Type | empty) statEnv |- Value matches Type? as I believe according to the formal semantics all processing instructions match processing-instruction("anything").
The fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification).
(personal response) I agree, the Formal Semantics does appear to be wrong in this respect. Proposed solution: A) The formal type system must model the target of a PI. In analogy to ElementType and AttributeType, we can define (in 2.4.2 Item types, duplicated in A.2): [? (Formal)] ProcessingInstructionType ::= "processing-instruction" PITargetOrWildcard [? (Formal)] PITargetOrWildcard ::= NCName | "*" In [27 (Formal)] ElementContentType, replace "processing-instruction" with ProcessingInstructionType B) Except as handled otherwise below, wherever processing-instruction appears as a type, replace it with processing-instruction * Specifically, that would be in: 3.5.1 / example 1,7 3.5.4 / Norm / rule 17,18,19,20,25,26 4.7.3.1 / STA / rule 1,2,3,4 4.7.3.1 / DEv / rule 1,2 4.7.3.3 / DEv / rule 1,2 4.7.3.5 / STA / rule 2 7.1.5 / STA / rule 1 7.1.6 / STA / rule 1 7.2.5 / STA / rule 3,4 7.2.6 / STA / rule 6 8.1.7 / Sem / rule 1,2 8.2.2.1.3 / Sem / rule 8,9 8.2.2.1.4 / Sem / rule 6 8.2.2.1.5 / Sem / rule 3 8.3.1 / Sem / rule 4 C) In 3.5.4 / Norm, delete the paragraph beginning "The [XPath/XQuery] type system does not model the target of a processing-instruction", and replace the two subsequent rules (21 & 22) with: [[ processing-instruction(NCName) ]]_sequencetype == processing-instruction NCName StringLiteral has atomic value String xs:NCName(String) = NCName -------------------------------------------------------- [[ processing-instruction(StringLiteral) ]]_sequencetype = processing-instruction NCName D) In 4.7.3.5 / STA / rule 1 / conclusion, change the type to processing-instruction NCName E) In 8.2.3.1.2 / Sem 4 (Processing instruction, comment, and text kind tests), replace rule 1 with: [[ PITest ]]_sequencetype = processing-instruction * ----------------------------- statEnv |- test PITest with PrincipalNodeKind of ProcessingInstructionType : ProcessingInstructionType And replace rule 2 with: [[ PITest ]]_sequencetype = processing-instruction NCName ----------------------------- statEnv |- test PITest with PrincipalNodeKind of processing-instruction NCName : processing-instruction NCName [[ PITest ]]_sequencetype = processing-instruction NCName ----------------------------- statEnv |- test PITest with PrincipalNodeKind of processing-instruction * : processing-instruction NCName ? F) In 8.3.1 / Sem, after rule 4, insert statEnv |- processing-instruction NCName { String } matches processing-instruction NCName
Here is an earlier discussion (member only) on this topic: http://lists.w3.org/Archives/Member/w3c-query-editors/2003Oct/0052.html Best regards Michael
Note that any resolution of this issue may also be reflected on the Static typing feature in the Update facility document (see Bug 4832). - Jerome
At its meeting on November 27th, the Joint XML Query WG and XSL WG approved the solution presented in Comment #2.
This issue has been entered as FS erratum E022, and its fix has been committed to the source files for the next edition of the FS document. Consequently, I'm marking this issue CLOSED.