This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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"?
Michael, Thanks for the comment. It seems that a somewhat cleaner way to write the semantics would be to introduce an auxiliary judgment to go from literalexpressions to literalvalues. This would be a bit less heavy-handed than a function. This could look as follows. Would that be better? - Jerome We could introduce an auxiliary judgement to go from the syntax tree literal to the value literal. As follows. Instead of writing: ------------------------------------------------------- dynEnv |- IntegerLiteral => xs:integer (IntegerLiteral) write: IntegerLiteral has literal value IntegerValue ------------------------------------------------------------- dynEnv |- IntegerLiteral => IntegerLiteral of type xs:integer Instead of writing: --------------------------------------------------- dynEnv |- DoubleLiteral => xs:double(DoubleLiteral) write: DoubleLiteral has literal value DoubleValue -------------------------------------------------------- dynEnv |- DoubleLiteral => DoubleValue of type xs:double where the has literal value raises a static error if the literal overflows. Instead of writing: --------------------------------------------------- dynEnv |- StringLiteral => xs:string(StringLiteral) write: StringLiteral has literal value StringValue -------------------------------------------------------- dynEnv |- StringLiteral => StringValue of type xs:string Where the judgment 'has literal value' deals with character references, and predefined entity references.
(In reply to comment #1) > > It seems that a somewhat cleaner way to write the semantics would be > to introduce an auxiliary judgment to go from literalexpressions to > literalvalues. This would be a bit less heavy-handed than a function. Fine with me. Am I right in thinking it would only have a prose definition? > IntegerLiteral has literal value IntegerValue > ------------------------------------------------------------- > dynEnv |- IntegerLiteral => IntegerLiteral of type xs:integer In the conclusion, the second "IntegerLiteral" should presumably be "IntegerValue". You have to be a little careful with terminology and symbology. In "X of type Y", X is (in these cases) AtomicValueContent, so the suggested 'FooValue' symbols don't fit. Instead, you'd want to use the alternatives under AtomicValueContent, specifically Decimal, Double, and String. That is: IntegerLiteral has literal value Decimal DecimalLiteral has literal value Decimal DoubleLiteral has literal value Double StringLiteral has literal value String You might consider changing "has literal value" to the more terminologically correct "has literal value content", although it's kind of clunky.
yes to all counts. we would only provide a prose definition for that judgment. IntegerValue was intended in that rule. We have to make sure the right hand side of the judgment is a formal value (grammar production AtomicValueContent) - Jerome
The proposed resolution in additional comment #1, along with your amendments has been adopted. - Jerome Simeon On behalf of the XML Query and XSL WGs