W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1374] [XQuery] some editorial comments on A.1 EBNF (notation)

From: <bugzilla@wiggum.w3.org>
Date: Fri, 08 Jul 2005 15:14:14 +0000
To: public-qt-comments@w3.org
Message-Id: <E1DquYQ-0001Ue-CX@wiggum.w3.org>


------- Additional Comments From scott_boag@us.ibm.com  2005-07-08 15:14 -------
> A.1 EBNF (notation)
> "The following term definitions ..."
>     Change "term definitions" to just "definitions".


> --------------------
> symbol
> "Each rule in the grammar defines one symbol, in the form ..."
>     This isn't a good definition for 'symbol'. But I'm not convinced it needs
>     one. (Note that the corresponding chunk of the XML spec doesn't bother
>     trying to define it.)  Maybe just drop the surrounding "[Definition:", 
> "]".

Done, un-termed.

> --------------------
> terminal
> "A terminal is a single unit of the grammar that can not be further subdivided,
> and is specified in the EBNF by a character or characters in quotes, or a
> regular expression."
>     This isn't a good definition for 'terminal'...

Redefined as part of the work to divide the terminals from the main grammar.

> "The following expressions"
>     Maybe change "expressions" to "constructs" or "patterns".
>     (Yes, the XML spec calls them 'expressions', but the XML spec doesn't use
>     the word for anything else. The XQuery spec certainly does.)

changed to "constructs".

> "are used to match strings of one or more characters in a terminal:
>     Delete "in a terminal". These constructs are also used in productions for
>     symbols that *aren't* listed as terminals in A.2.1.
> #xN
> [#xN-#xN]
> [#xN#xN#xN]
> [^#xN-#xN]
> [^#xN#xN#xN]
>     The XQuery grammar doesn't use any of these constructs. Delete them.

Removed (or at least hidden via the XML, in case they're needed later).

> [^a-z]
>     The XQuery grammar doesn't use this either.


> "[abc] Enumerations and ranges can be mixed in one set of brackets."
> "[^abc] Enumerations and ranges of forbidden values can be mixed in one set of
> brackets."
>     The XQuery grammar doesn't mix enumerations and ranges.


> "matches a literal string matching that given inside the double/single quotes."
>     Throughout this section, the usage of "matches" is:
>         {construct in the grammar} matches {characters in a query}
>     (As such, it means roughly the same as "derives" in its technical sense.)
>     However, this sentence adds the usage
>         {characters in a query} matching {characters in the grammar}
>     which reverses the sense.
>     How about this:
>         "matches the sequence of characters that appear inside the double/single
>         quotes"

Text adapted.

> "matches a production"
>     No, matches any string matched by that production.


> "For the purposes of this secificiation"
>     Fix typo: "specification"


> "the entire unit is defined as a terminal."
>     Actually, you should probably delete this sentence.  Rather than saying the
>     [http:...] construct is a terminal, it's simpler and presumably equivalent
>     to just designate the production's LHS symbol as a terminal.  (According to
>     A.2.1, CharRef, QName, NCName, and S have already been handled this way.
>     PITarget and Char haven't.)

Sentence deleted.

> So, covering the last two points, you could replace the paragraph with
> something like:
>     "Patterns (including the above constructs) can be combined with
>     grammatical operators to form more complex patterns, matching more
>     complex sets of character strings. In the examples that follow,
>     A and B represent (sub-)patterns."

Text adapted.

> "(expression)"
>     Change to "(A)" -- you've already set up A as a placeholder, so why not
>     use it.


> A B
> "This operator has higher precedence than alternation; thus A B | C D is
> identical to (A B) | (C D)."
>     As far as I can tell, constructs such as 'A B | C D' do not occur in the
>     XQuery grammar , so it is unnecessary to define the relative precedence
>     of juxtaposition and '|'. Delete the sentence.

No.  That construct occurs often if you accept that angle-bracket groups have no
definitional significance.


[38] OrderByClause ::= (<"order" "by"> | <"stable" "order" "by">) OrderSpecList

In the main exposition, where angle brackets are not used:

[38] OrderByClause ::= ("order" "by" | "stable" "order" "by") OrderSpecList

Otherwise, we need to define <A B> in terms of (A B), and in that case, the
parens need to be put in the exposition, which would look pretty ugly and
unnecessary in many places.

> A+
> "thus A+ | B+ is identical to (A+) | (B+)"
>     No such constructs occur. Delete the sentence.
> A*
> "thus A* | B* is identical to (A*) | (B*)"
>     No such constructs occur. Delete the sentence.

Given that I think I've established that we need the precedence for A B, I would
prefer to go ahead and define the precedence for these, even if not used.

> (angle-bracket groups)
>     Since the angle-bracket group is a notation used in the grammar, it should
>     be defined here. I suggest putting it right after "(expression)", since
>     it has a similar flavour. (In each case, the grouped construct matches the
>     same thing as the ungrouped construct.)

Received on Friday, 8 July 2005 15:14:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC