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: <50DE8619.9090003@gmail.com>
Date: Sat, 29 Dec 2012 13:56:41 +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>
References: <50DCD850.3020106@alum.mit.edu> <50DD1326.5040100@gmail.com>
	<50DD2DD0.8080301@alum.mit.edu>
In-Reply-To: <50DD2DD0.8080301@alum.mit.edu>
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

OK, yes agreed. A simple way to extract (and hyperlink) grammars across =

multiple documents would be very useful.

Forget the test case issue. I now realize to embed that adequately could =

clutter documents a little too much.

Has there ever been a similar proposal for delimiting and automating =

extraction of sample code from RFCs?

- Daniel


On 28/12/12 13:27, Paul Kyzivat wrote:
> 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