Subject: Seeking clarification of ABNF "name formation" reference

From: Dave Crocker <[email-masked]>
Date: Mon, 21 May 2007 17:47:05 -0700

Folks,

In the ABNF document, there is a precedence chart:

> <section title="Operator Precedence">
 >
>             <t> The various mechanisms described above have the following
>                precedence, from highest (binding tightest) at the top, to
>                lowest (loosest) at the bottom: <list>
 >
>                   <t>Strings, Names formation</t>
>                   <t>Comment</t>
>                   <t>Value range</t>
>                   <t>Repetition</t>
>                   <t>Grouping, Optional</t>
>                   <t>Concatenation</t>
>                   <t>Alternative</t>
 >
>                </list>
>             </t>

The reference to "Name formation" has been in this form since RFC 2234.

Oddly, we can't figure out what it is supposed to mean, exactly.

We could make some guesses, but I'd rather check with the group.

Comments?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Philip Guenther <[email-masked]>
Date: Tue, 22 May 2007 00:29:38 -0600

>>                   <t>Strings, Names formation</t>
...
> We could make some guesses, but I'd rather check with the group.

My guess was that it's a reference to the 'prose' value form, ala:
 	tag      = 1*<any ASTRING-CHAR except "+">

Inside the angle-brackets, only close-angle-bracket is special, just as 
inside a string, only double-quote is special, so those forms have a 
higher precedence than comment (semicolon isn't special) and repetition 
(asterisk isn't special), and...

So then I looked at the RFC and discovered that the prose value form is 
*only* mentioned in the ABNF definition of ABNF!  Was its prose 
description misplaced and accidentally used to shim a wobbly table?  If 
so, that would explain the dangling reference.

Philip Guenther

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 May 2007 11:23:30 +0100

> We could make some guesses, but I'd rather check with the group.

I guess that "strings" means any terminal value, including % numeric
character specifiers even though it usually means only quoted strings.

I guess that "names formation" (sic) refers to rule names.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWEST VEERING WEST 5 OR 6 INCREASING 7 TO SEVERE GALE
9. ROUGH INCREASING VERY ROUGH OR HIGH. SHOWERS BECOMING WINTRY. GOOD.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 23 May 2007 09:46:51 +0100

>>                  <t>Grouping, Optional</t>

If "value range" means the "%x20-3F" construct, then that has higher
precedence than comment, I would suggest. More significantly, repetition
has lower precedence than grouping and optional: this is shown firstly by
the formal grammar, and secondly because "*(A B)" means zero or more sets
of A-then-B, while if repetition had higher precedence then it would mean
zero or more As followed by one B (that is, the same as "((*A) B)").

> The reference to "Name formation" has been in this form since RFC 2234.

I assumed it was <prose-val>.

However, as Philip points out, it's not defined anywhere in sections 2 or
3. Rather, 2.1 implies that the "<rulename>" form can occur on the left of
the <defined-as> if the author wants. This means that the grammar should
have the following definitions for rulename:

    rulename = ub-rulename / "<" ub-rulename ">"
    ub-rulename = ALPHA *(ALPHA / DIGIT / "-")

I've used "ub-rulename" to mean "unbracketed rulename"; feel free to change
it.

Is it intentional to allow <rulename> to end in a hyphen?

As well as needing a textual description of <prose-val>, there are two other
considerations:
(1) the comment implies that "<" cannot occur in a <prose-val>, but the
    formal grammar allows it;
(2) with the above change, the grammar is ambiguous, because "<rulename>"
    can be either a <rulename> or a <prose-val>. This needs disambiguating
    in some way, either in a comment or by requiring a prose-val to contain
    a non alphanumeric character (which might be space).

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 May 2007 13:46:58 +0200

> zero or more As followed by one B (that is, the same as "((*A) B)").

Maybe we could have the individual items in the precedence list 
reference either subsections in section 3, or rule names in section 4?

> have the following definitions for rulename:

Maybe we should check whether that is used in practice, and what the 
parser implementations do with it.

>     formal grammar allows it;

Right.

>     a non alphanumeric character (which might be space).

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 May 2007 14:15:24 -0700

Folks,

I think we figured out what this was about.  The 'name formation' meant the 
aggregation of characters that form a rulename.

The revised precedence list reads:

 > >                  <t>Rule name, prose-val, Terminal value<t>
 > >                  <t>Comment</t>
 > >                  <t>Value range</t>
 > >                  <t>Repetition</t>

We believe that each item on the first line is explained with existing 
definitions or text.

d/
-- 

   Dave Crocker