Message-Id: <200007121135.HAA08035@astro.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Nick_Shelness@motorcity2.lotus.com
cc: Keith Moore <moore@cs.utk.edu>, drums@cs.utk.edu
Subject: Re: ABNF sets and sequences 
In-reply-to: Your message of "Wed, 12 Jul 2000 08:46:25 BST."
             <8525691A.002AA70A.00@motorcity2.lotus.com> 
Date: Wed, 12 Jul 2000 07:35:06 -0400
Sender: moore@cs.utk.edu

Nick,

one problem I have with the 

        valid = { [ a ] b *c }

notation is the use of [ ] and * to mean things that are actually
quite different from the use of these symbols outside the { and }.

while it's true that human languages often change the meaning of
words or symbols based on subtle differences in context, a language 
like ABNF, intended for use in writing technical specifications, needs 
to be less ambiguous than that.   especially when in practice it seems
likely that there will be a need to use both kinds of * or
[ ] in close proximity to one another.

that, and I can't see any way, using the notation above, to say
something like "you can define your own names for addiional parameters 
but none of these may appear more than once". as would presumably
be the case for content-disposition parameters, content-type parameters,
RFC 1894 per-recipient or per-message indicators, etc.

now, we could pick different characters to mean "it's an error if
this symbol is matched more than once within this rule" (say %) or 
"it is an error if this symbol does not match at least once within 
this rule" (say &).  so we would then have

	header = *(
		%&to_field /
		%from_field /
		%sender_field /
		%subject_field /
		received_field 
	)

but offhand I still don't see a way to specify "sender_field must be
present if from_field is missing" with a notation like this.  

and I still find it both clearer, and more useful from an implementor's
point-of-view, to separate "parsing" from other kinds of syntax checking.

Keith