W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2007

[Bug 4274] Static typing of Comp-notation-*

From: <bugzilla@wiggum.w3.org>
Date: Tue, 23 Jan 2007 13:44:59 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1H9LxL-0000wn-Sb@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4274

           Summary: Static typing of Comp-notation-*
           Product: XML Query Test Suite
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XML Query Test Suite
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: nick@cbcl.co.uk
         QAContact: public-qt-comments@w3.org


Comp-notation-*, while it should be possible to infer the types correctly,
unfortunately fail to static type check when following the rules in the formal
semantics due to a quantifier mismatch

(: Name: Comp-notation-1 :)
(: Written by: Andreas Behm :)
(: Description: notation comparison :)

(: insert-start :)
import schema namespace myns="http://www.example.com/notation";
declare variable $input-context as document-node(schema-element(myns:allTypes))
external;
(: insert-end :)

fn:not($input-context//*:NOTATION1 eq $input-context//*:NOTATION3)


// normalizes to descendant-of-self() [FS 4.2]

This always has quantifier '*' [FS 8.2.2.1.8]

The step expression becomes a FLWOR expression [FS 4.2]

This returns a type with the quantifier of the descendant-or-self() [FS 4.8.2]

statEnv |-  Expr1 : Type1
...
-------------------------
statEnv |-  for $VarName1 in Expr1 return Expr2 : Type2  quantifier(Type1)

Therefore the static typing of the path expression will always have the '*'
quantifier which causes a static typing exception with the operators, like eq,
which expect a quantifier of one.

If should theoretically be possible to infer a type without the '*' quantifier
for the descendant-or-self() step in these tests due to the schema information,
so I can report this as a bug in the Formal Semantics instead if people think
that is more appropriate.

Otherwise, could // be replaced by the full path?
Received on Tuesday, 23 January 2007 13:45:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:32 UTC