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: <50DD1326.5040100@gmail.com>
Date: Fri, 28 Dec 2012 11:33:58 +0800
From: Daniel van Vugt <vanvugt@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, abnf-discuss@ietf.org
References: <50DCD850.3020106@alum.mit.edu>
In-Reply-To: <50DCD850.3020106@alum.mit.edu>
Subject: Re: [abnf-discuss] Some thoughts about how to make ABNF more
 convenient to use
Precedence: list
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: abnf-discuss-bounces@ietf.org
Errors-To: abnf-discuss-bounces@ietf.org

I like the idea of automating retrieval of a complete grammar from =

multiple documents. However if the end goal is to give the grammar to a =

checker/compiler then maybe that issue needs to be considered =

holistically first...

Even if your grammar compiles and is not ambiguous in any way, you =

cannot really be confident of its correctness for the intended task =

without some test input. Where does that come from? If there is no test =

input (presumably from the same documents) then what is the value in =

automation?

It sounds like you could only automate a syntax check in most cases. Is =

that a sufficiently strong end goal? I'm concerned for more subtle =

errors such as ambiguities I found in the ABNF RFC and XML spec when =

building Dapar[1]. Those require test cases to accompany the grammar.

[1] http://sourceforge.net/projects/dapar/

- Daniel


On 28/12/12 07:22, Paul Kyzivat wrote:
> [Is this list live? As best I can tell there has only been one message,
> ever.]
>
> I've been observing problems with the mechanics of using ABNF for ietf
> drafts, and contemplating some changes that could make things better.
> But I'd like to get some support and feedback before doing much about it.
>
> I would like to better support current practice where one draft or RFC
> extends the ABNF from another draft or RFC, or references ABNF rules
> defined elsewhere when defining something new.
>
> In my experience this is done using comments that identify the source of
> the referenced definitions. Formally processing this requires manual
> actions to cut and paste definitions from multiple documents in order to
> create a single ABNF source that can be processed for formal tools.
>
> With the enhancements I have in mind, it will be possible to build ABNF
> tools that automatically extract the required definitions.
>
> Also, often RFCs prefer to interleave ABNF rule definitions with
> descriptive text. But that makes it difficult to process. Sometimes
> rules are interleaved, and then also gathered together into a full ABNF,
> but this runs a risk of divergence. I'd also like to help with that.
>
> The enhancements I have in mind are:
>
> Extend ABNF syntax with:
> =95 A way to assign a name to a rule list within a document.
>    This allows multiple independent groups of rules to be defined
>    within a single document and referenced independently.
>
> =95 A way to reference a rule defined in a named collection of rules.
>
> =95 A way to import rule definitions from another document.
>    Optionally reference a specific named rule list within that document.
>
> Extend xml2rfc with:
> =95 A way to tag sections of the document that contain ABNF, so that
>    its easy to extract just the ABNF from the XML document.
>
> With these changes, an ABNF checker/compiler could be given the name of
> a draft or rfc, and could directly process the ABNF within. And that
> draft could reference and extend ABNF in another draft or rfc, and the
> checker/compiler could automatically retrieve that as well.
>
> Do others think this would be useful?
>
>      Thanks,
>      Paul
> _______________________________________________
> 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