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: <50DD2DD0.8080301@alum.mit.edu>
Date: Fri, 28 Dec 2012 00:27:44 -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: Daniel van Vugt <vanvugt@gmail.com>
References: <50DCD850.3020106@alum.mit.edu> <50DD1326.5040100@gmail.com>
In-Reply-To: <50DD1326.5040100@gmail.com>
Cc: abnf-discuss@ietf.org
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

On 12/27/12 10:33 PM, Daniel van Vugt wrote:
> 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?

What is the value?
- When I, as document shepherd, am writing my shepherd doc on a draft,
   I'm supposed to verify that the ABNF is syntactically correct.
   Right now that can be a pain. This would make that dead simple.

- Similarly, if I am *implementing* a draft, I may want to feed the
   ABNF into a compiler. All the same issues apply.

- If the ABNF can be scattered through a draft, interspersed with
   descriptive and normative text, and still be easily gathered together
   for processing, then it may lead to more nicely structured drafts.

Testing is an entirely different issue.

> 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.

By test cases, do you simply mean text that should match some particular =

rule?

If we want that, then we need, in addition to what I am suggesting:
- a standard tool that takes ABNF, the name of a rule, and some text,
   and verifies if the text matches the rule.

- Some agreed upon format for publishing ABNF test cases.

Those could be interesting. But I would consider that a separate effort.

	Thanks,
	Paul

> [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