W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: ABNF switch: list rules

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 25 May 2008 09:45:14 +1000
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7E528A7D-41D4-4B27-830F-13323CD6BC28@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 24/05/2008, at 6:13 PM, Julian Reschke wrote:

> Henrik Nordstrom wrote:
>> On fre, 2008-05-23 at 15:19 +0200, Julian Reschke wrote:
>>> The more I look into this, the better the original syntax looks :-)
>> Yes, there is reasons why HTTP has the list syntax.. and I think that
>> one does a great job in keeping the BNF readable.
>> The reasons for the implied LWS is the same, to make the grammar more
>> readable, but unfortunately that one hasn't worked out very well..
>> If we can get the BNF syntax to a level of
>>  ABNF + list syntax, without implied LWS
>> then a lot is gained.
> Right.
> In particular it seems it would be wise to solve the "implied LWS"  
> issue *first*, and only then start looking at the list production.


>> Eleminating the list syntax is mainly a goal to line up the HTTP BNF
>> syntax completely with other specifications, but I have a feeling  
>> that
>> it may be better to extend ABNF with a usable list construct.
> I'd prefer that.
> If we can't keep it, I'd probably recommend to leave the # notation  
> at least in ABNF comments.


>> While we are at that topic. The specification probably should make  
>> sure
>> to recommend producers to not produce lists with empty elements (a
>> SHOULD NOT). Not sure we have that in the specs today. Parsers MUST
>> accept them however and is what the BNF description describes but  
>> there
>> quite likely is many broken implementations out there not expecting
>> empty elements..
> What do others think? Is there consensus for this? In which case we  
> should raise a separate issue.
> BR, Julian

Mark Nottingham     http://www.mnot.net/
Received on Saturday, 24 May 2008 23:45:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC