- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 18 Apr 2006 03:13:49 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1535
------- Comment #5 from jmdyck@ibiblio.org 2006-04-18 03:13 -------
(In reply to comment #4)
>
> I have some reservation about the last suggestion however, about
> an alternative grammar & approach. More specifically, I am not sure
> that using `1` instead of xs:integer("1") is that much clearer.
Where did xs:integer("1") come from? As far as I can tell, xs:integer("1")
cannot be derived from AtomicValueContent, so is not under discussion. I was
suggesting using `1` instead of 1, and `foo` instead of "foo", (etc.) *only* in
the context of AtomicValueContent.
> It introduces new notations
One new notation.
> which seem really unnecessary in that
> case and will need some extra explainations.
You think you can reuse old notation without extra explanations?
> Here is an interim suggestion, which instead relies more explicitely on
> XQuery's syntax and is closer the first proposal you are hinting at.
That wasn't a proposal, it was more of a rhetorical device. I think it's a bad
idea to use XQuery syntax, because:
-- it makes it look like XQuery is being defined in terms of itself;
-- I think some readers would be confused about the different uses of
StringLiteral etc.; and
-- it's possible that some inference rules might get "confused" too.
> It would look like the following:
>
> AtomicValueContent ::= StringLiteral
> | BooleanLiteral
> | DecimalLiteral
> | DoubleLiteral
> | ConstructedLiteral
You'd have to go to each occurrence of 'String' and change it to
'StringLiteral' if appropriate. Similarly for Boolean, Decimal, Double. I don't
think the result would be an improvement. Consider what would happen to the
rules in 4.1.1.
Plus, you'd have to go to each occurrence of 'AnyURI' and 'expanded-QName' and
change them to 'ConstructedLiteral' if appropriate, which I doubt you want to
do. (The other symbols on the rhs of AtomicValueContent's current production
don't seem to occur in the FS.)
People might wonder "Why no FloatLiteral? Or DateLiteral? Why do
String/Boolean/Decimal/Double get preferred treatment?" (And really, the answer
is that there's no reason for them to get preferred treatment here, other than
that the examples in 2.3.2 were written in a particular way.)
Given ConstructedLiteral, {String,Boolean,Decimal,Double}Literal are redundant
here.
> DecimalLiteral ::= Digit+ ( "." Digit+ )?
> DoubleLiteral ::= (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
Note that these don't provide a literal for every value in the decimal or
double value spaces.
> ConstructedLiteral ::= AtomicTypeName "(" StringLiteral ")"
>
> * In the ConstructedLiteral form, the corresponding string literal
Don't use "corresponding" here if that's the word chosen to signal the
syntactic/abstract divide. (Also don't say "string literal" if you mean
"StringLiteral".)
> must be a valid lexical representation for the corresponding value
> in the specified atomic type.
The phrasing is somewhat backwards, since it suggests that you already know the
corresponding value, and thus what its valid lexical representations are. Maybe
change "the corresponding value" to "some value" or "a value".
And it's not quite correct to say that the string literal is a valid lex rep;
instead, the *content* of the string literal (roughly, the stuff between the
quotes) is.
....
On a separate note, it occurred to me that it might make more sense if
'AtomicValueContent' were named 'PrimitiveValue'.
Received on Tuesday, 18 April 2006 03:13:53 UTC