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

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





------- 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".

Done.

> 
> --------------------
> 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.

Removed.

> 
> "[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.

Removed.

> 
> "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.
> 

Fixed.

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

Fixed.

> 
> "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.

Done.

> 
> 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.

Example:

[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.)

Done.

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