W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2006

[Bug 1804] [FS] editorial: E.1.4.2 Erases

From: <bugzilla@wiggum.w3.org>
Date: Mon, 17 Apr 2006 15:45:06 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1FVVuU-00019u-QX@wiggum.w3.org>

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





------- Comment #13 from simeon@us.ibm.com  2006-04-17 15:45 -------
Michael:

Thanks for the response. I am now convinced we have distinct interpretations
for what the meaning of non-terminals in judgments is.

Just to make sure we are on the same page, it seems that the main difference
between our two interpretation is that you assume that non-terminals names
which are used in the grammar to describe the syntactic objects end up being
part of the syntactic objects themselves. On the other hand, I assume that the
syntactic objects are defined independantly of the non-terminal names being
used and that only terminals are part of those syntactic objects.

Now, I would like to argue that my interpretation is actually consistent with
the current Formal Semantics draft, that it does not raise any specific
additional issue. A few specific points on this:

About ASTs. As your point out, the processing model mentions a notion of AST.
However the specification does not make any specific assumption about what such
an AST might be. In particular it does not assume that non-terminal names
should be part of that AST. I believe this terminology is used since it is
quite familiar to developers, but that this does not enforce any specific way
to represent the syntactic objects resulting from grammar productions in the
formal semantics.

The interpretation of non-terminals in the grammar is actually described in
Section 2.1.2 Notations for judgments, as follows:

<<
Patterns are used to represent objects that can be constructed from a given
grammar production. In patterns, italicized words correspond to non-terminals
in the grammar. The name of those non-terminals is significant, and may be
instantiated only to an "object" (a value, a type, an expression, etc.) that
can be substituted legally for that non-terminal. For example, 'Expr' is a
pattern that stands for every [XPath/XQuery] expressions, 'Expr1 + Expr2' is a
pattern that stands for every addition expression, 'element a { Value }' is a
pattern that stands for every value in the [XPath/XQuery] data model that is an
'a' element.

When instantiating the judgment, each pattern must be instantiated to an
appropriate sort of "object" (value, type, expression, etc). For example, '3 =>
3' and '$x+0 => 3' are both instances of the judgment 'Expr => Value'. Note
that in the first judgment, '3' corresponds to both the expression '3' (on the
left-hand side of the => symbol) and to the value '3' (on the right-hand side
of the => symbol).
>>

I don't believe that those description indicate that non-terminals are part of
the objects themselves. I agree that maybe some more clarification about what
we mean by objects (syntactic?) here and how they relate to actual objects
(values, expressions) is completely specified. No matter what I think there is
no completely formal way to explicit that relationship, but if you want to
suggest some text that you believe would make it clearer, that would sure be
greatly appreciated.

On the technical front, I am worried that your interpretation will not work
with most of the auxiliary judgments that are introduced in the spec. For
instance, the section on FLWORs starts as follows:

4.8.1 FLWOR expressions

Notation

For convenience, we introduce the following auxiliary grammar productions.
[87 (Formal)]           OptTypeDeclaration         ::=         
TypeDeclaration?
[88 (Formal)]           OptPositionalVar           ::=          PositionalVar?

And those non-terminals are used in judgments.
It seems that an expression Expr considered with your interpretation will never
match with those formal non-terminals since they are not part of the main
grammar. I think this is used all over the place and switching to your
interpretation will require some fairly involved changes (including probably to
the original XQuery grammar which probably will be hard at this point).

Finally, I am not sure I see what current problem we are trying to fix. Is
there really anything broken currently? It seems to me just a matter of style.
Did I miss another technical problem?

Cheers,
- Jerome
Received on Monday, 17 April 2006 15:45:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:11 UTC