Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1890:126c::1:1e as permitted sender) client-ip=2001:1890:126c::1:1e;
Message-ID: <50E46663.4080506@alum.mit.edu>
Date: Wed, 02 Jan 2013 11:54:59 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Dave Crocker <dcrocker@gmail.com>
References: <50DCD850.3020106@alum.mit.edu>
	<alpine.LSU.2.00.1301021022570.15409@hermes-1.csi.cam.ac.uk>
	<50E45623.9060607@gmail.com>
	<alpine.LSU.2.00.1301021552190.15409@hermes-1.csi.cam.ac.uk>
	<50E45B21.20509@gmail.com>
	<alpine.LSU.2.00.1301021611070.15409@hermes-1.csi.cam.ac.uk>
	<50E460D0.1020308@gmail.com>
In-Reply-To: <50E460D0.1020308@gmail.com>
Cc: Tony Finch <dot@dotat.at>, abnf-discuss@ietf.org
Subject: Re: [abnf-discuss] Some thoughts about how to make ABNF more
 convenient to use
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: abnf-discuss-bounces@ietf.org
Errors-To: abnf-discuss-bounces@ietf.org

I've been working on a proposal for enhancements for importing, and for 
namespaces. IMO you must have namespaces if you are to have importing, 
to avoid clashes between definitions in independently developed rule 
sets that are slightly linked.

My initial mail was to size up the interest, and flush out what has 
already been considered, before finalizing my thinking. Discovering that 
tagging for the ABNF is already supported is a real plus.

Regarding different "languages" in the same document:

Namespaces could help, but IMO are less urgent in this case. It should 
be easy to keep the grammars from clashing on rule names, and quite 
likely that they will share rules.

ISTM that the when defining "languages" via ABNF the key is to identify 
the top level rule that is the goal for a particular language. If there 
are several languages, then each will have a particular goal rule. An 
obvious example of this is when ABNF is used to define messages. If 
there are several messages, then there will be a goal rule for each. 
These may share a bunch of sub-rules.

If someone is building a parser, and is only needs support for one goal 
rule, then it is relatively trivial to prune out any rules that are not 
needed to support that one. If a document has multiple independent 
language definitions, then it should be clear when parsing the ABNF that 
there are totally independent trees of rules that don't interact with 
one another.

Of course namespaces will make it easier to construct disjoint rulesets 
within a document, if that is the intent.

	Thanks,
	Paul

On 1/2/13 11:31 AM, Dave Crocker wrote:
>
>
> On 1/2/2013 8:24 AM, Tony Finch wrote:
>> Dave Crocker <dcrocker@gmail.com> wrote:
>>> On 1/2/2013 7:57 AM, Tony Finch wrote:
>>>> Dave Crocker <dcrocker@gmail.com> wrote:
>>>>>
>>>>> It would need to be able to distinguish among potentially
>>>>> independent sets of rules, within a spec. We don't currently have a
>>>>> way to indicate that.
>>>>
>>>> Has there ever been any need for it?
>>>
>>> Well, ummm, RFC822 had several parsers, such as for addresses versus
>>> dates
>>> versus free-form like Subject.  Applications often need this, I believe.
>>
>> Hmm, well I would describe those as sub-languages whereas I thought we
>> were talking about independent languages. But in both cases they can be
>> defined / identified using the transitive closure from the starting rule,
>> without revising ABNF.
>
> I don't think so.  The parsing rules for a date field are quite
> different than for an an address field, in 822.  They share some lexical
> constructs, of course, but I don't find that very significant for the
> current topic.
>
>
>> I can see that rule sets might be useful for importing collections of
>> low-level rules, like the ABNF core rules.
>
> The choice, here, is between a formally flat namespace versus one that
> is formally able to be partitioned.  Simplicity is the major benefit of
> the first, of course.  Rigor and the ability to enforce the package
> boundaries that are actually present are the benefits of the latter.
>
>
>>> What I don't know is whether there will be the community will to
>>> pursue it --
>>> will we see enough operational benefit?
>>
>> I think a formal import mechanism would be very useful and could be quite
>> easy to deploy. Adding namespaces will be a lot of work.
>
> ack.
>
> Given the effort to make /any/ changes to a package like abnf, I thought
> it worth raising the additional issue, since it seemed to develop pretty
> naturally from the thread.  But again, I don't have any idea whether
> anyone else thinks it's worth pursuing...
>
> d/

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss