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: <50E737AF.30102@alum.mit.edu>
Date: Fri, 04 Jan 2013 15:12:31 -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: abnf-discuss@ietf.org
References: <20130103171755.20983.75939.idtracker@ietfa.amsl.com>
	<50E5BF59.9000207@alum.mit.edu> <50E5D4C5.8010800@alum.mit.edu>
	<tk0GjBDTOy5QFAkk@paul.bayleaf.org.uk>
In-Reply-To: <tk0GjBDTOy5QFAkk@paul.bayleaf.org.uk>
Subject: Re: [abnf-discuss] A proposal for adding import and scopping to ABNF
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: abnf-discuss-bounces@ietf.org
Errors-To: abnf-discuss-bounces@ietf.org

Inline

On 1/4/13 1:46 PM, Paul Overell wrote:
>
> Hi,
>
> In message <50E5D4C5.8010800@alum.mit.edu>, Paul Kyzivat
> <pkyzivat@alum.mit.edu> writes
>
> I think this is a very interesting idea, to formalize import and export
> of ABNF between documents.  Some thoughts, questions and quibbles:
>
>
> 1)
>
>>       named-rulelist =
>>          rulelist-name *WSP "{" rulelist "}" c-nl
>>
>>       rulelist-import =
>>          (basic-import / named-import) c-nl
>
> I think there is a minor problem with the syntax here, it doesn't allow
> *WSP before the c-nl.

Yeah, you seem to be right. Would you be happy with:

      named-rulelist =
          rulelist-name *WSP "{" rulelist "}" *WSP c-nl

       rulelist-import =
          (basic-import / named-import) *WSP c-nl


>  But be very careful when fixing this as the
> original syntax contains some ambiguity concerning white space, which is
> subject to an errata:
> http://www.rfc-editor.org/errata_search.php?rfc=5234&rec_status=2&present
> ation=records.
>
> 2)
>
>>   o  The <basic-import> simply inserts all the ABNF from the referenced
>>      document.
>>   o  The <named-import> is similar, but does the import within a new
>>      <named-rulelist>.  This is just syntactic sugar, but is
>>      convenient.  E.g. the following:
>>
>>       CORE@"urn:ietf:rfc:5234"
>>
>>      is equivalent to:
>>
>>       CORE {
>>          @"urn:ietf:rfc:5234"
>>       }
>
> This doesn't seem to allow importing just a named-rulelist from another
> document.  E.g if document 1 has
> SYNTAX1 {
>     doc1syntax1 = ...
> }
> SYNTAX2 {
>     doc1syntax2 = ...
> }
>
> How do I specify in document 2 that I wish to import just SYNTAX1, and
> not SYNTAX2?
>
> The named-import seems to import ALL the ABNF from another document into
> a new namespace - or have I misunderstood?

It *doesn't* provide a way to do that.

I initially did try to do that. Fitting it into the syntax was no 
problem, but it introduces extra potential error cases (notably - 
recursive imports), and would significantly complicate an 
implementation. (You have to parse the imported file and build at least 
a partial symbol table in order to find the part you want to import. But 
then you must at least re-resolve all the rulename references in the new 
context.)

So I decided to follow the KISS principle and just leave that feature 
out. It doesn't really hurt to import more, except for efficiency. And 
efficiency isn't really an issue when processing ABNF.

> 4)

What happened to (3)?

> Have you considered an import syntax to specify importing just a
> specific rule or list of rules?  E.g. Importing from RFC5234 one might
> just want some of the core rules from Appendix B, but not want the ABNF
> Definition of ABNF in section 4.

Yes. KISS again. Also, IMO it is very unlikely that one would want to 
import just one rule. You can get a similar effect by:

CORE@"urn:ietf:rfc:5234"
ALPHA = CORE.ALPHA
DIGIT = CORE.DIGIT


> 5)
>
> What are the semantics of importing a rulelist that itself imports a
> rulelist?  Is circularity allowed (doc1 import from doc2, doc2 imports
> from doc1)?  If so is a parser expected to detect circularity to avoid
> an infinite loop?

As mentioned above, this is one reason I abandoned importing specific 
named rulesets.

The parser needs to detect this well enough to avoid crashing by running 
out of resources.

Recursion can be detected by, at the time of import, searching up the 
stack of in-progress imports for a file with the same name. If found, 
abort the import and report an error.

This works *because* the import is all-or nothing, rather than by 
selectively importing a named-rulelist. If that is supported then it 
gets much more complicated.

	Thanks,
	Paul K

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss