- 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