W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1566] New: [FS] technical: 4.1.1 Literals

From: <bugzilla@wiggum.w3.org>
Date: Wed, 13 Jul 2005 08:27:08 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DscaC-0002yn-W2@wiggum.w3.org>

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

           Summary: [FS] technical: 4.1.1 Literals
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


4.1.1 Literals

Normalization
"Predefined entity references and character references in strings are
resolved to characters as part of parsing"
    Oh? I don't think that's specified anywhere. And I don't think it
    should be. It's part of the semantics of string literals, and you
    shouldn't just foist it onto the parser.

DEv / rule 1 / conclusion 1
DEv 2 / rule 1 / conclusion 1
DEv 3 / rule 1 / conclusion 1
DEv 4 / rule 1 / conclusion 1
"dynEnv |- FooLiteral => xs:foo(FooLiteral)"
    The xs:foo constructor function expects an argument value of type
    xdt:anyAtomicType. The 'FooLiteral' pattern is bound to (say) a node
    in the syntax tree of the subject query, which is not a value of
    xdt:anyAtomicType. So it shouldn't appear as the argument to xs:foo().

    You need a mechanism (say, fs:literal-to-string()) to go from a node
    in the syntax tree to a value of xs:string (I think) that contains
    the sequence of query characters covered by that node. (Also, for
    string literals, you'll need a function to strip the delimiters and
    "un-double" any occurrences of the delimiter-character.)


"Note that literal overflows are raised during parsing."
    Again, this is not something that should be foisted onto the parser.
    Note that the constructor function will raise an error if its arg is
    illegal for the target datatype; is that sufficient to handle "literal
    overflows"?
Received on Wednesday, 13 July 2005 08:27:11 UTC

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