- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 13 Jul 2005 08:27:08 +0000
- To: public-qt-comments@w3.org
- Cc:
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