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;
MIME-Version: 1.0
In-Reply-To: <50E460D0.1020308@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>
Date: Wed, 2 Jan 2013 18:14:33 +0100
Message-ID: <CABSMSPXthVjLT1e6MgoAwK+3W6-kSimE+XJ_UnKA4ZQgm3vjqA@mail.gmail.com>
From: Riccardo Bernardini <framefritti@gmail.com>
To: abnf-discuss@ietf.org
Subject: Re: [abnf-discuss] Some thoughts about how to make ABNF more
 convenient to use
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: abnf-discuss-bounces@ietf.org
Errors-To: abnf-discuss-bounces@ietf.org

On Wed, Jan 2, 2013 at 5:31 PM, Dave Crocker <dcrocker@gmail.com> 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...
>

I like the idea of namespaces. It is true that you can live without
them and you can use informal PMNS (Poor Man Name Space) by adding a
prefix; nevertheless, I think that formally defined namespaces are a
definite plus.

I speak from experience: I worked both with languages (like C) without
namespaces where, to avoid clashes, you must resort to the "prefix
trick" and languages (like Ada) where every package has its own
namespace and I must say that it is much easier to work with the
latter...

BTW, inspired by Ada, you could use the RFC number as the namespace
itself, e.g., RFC4566.proto-version.  More complex RFCs with different
languages could define sub-spaces, e.g.,
RFC9999.fictional-namespace.foo.  This convention could (potentially)
be automatically checkable and maybe hyper-links automatically
inserted in the HTML/PDF version.

Since I am here, I would add a "desiderata" that is more about xml2rfc
than ABNF: the last time I used xml2rfc (maybe things changed since
then), if the ABNF section was not strictly correct, xml2rfc would
give a warning like "warning: not strictly conformant,"  without being
more specific and giving as reference the first line of the ABNF
section.  A more detailed message would help.

Riccardo

>
> d/
> --
>  Dave Crocker
>  bbiw.net
> _______________________________________________
> abnf-discuss mailing list
> abnf-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/abnf-discuss
_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss