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: <50DE8996.2030207@alum.mit.edu>
Date: Sat, 29 Dec 2012 01:11:34 -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>
	<50DD2DD0.8080301@alum.mit.edu> <50DE8619.9090003@gmail.com>
In-Reply-To: <50DE8619.9090003@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/29/12 12:56 AM, Daniel van Vugt wrote:
> 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?

I don't know. That's why I'm asking.

	Thanks,
	Paul

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