Fwd: Re: on grammars and parsing algorithm

Related to ISSUE-19.

If anyone (such as Yves) has specific ideas on how to move forward (on top  
of my suggested changes or instead of them), that would be useful.

Philip

------- Forwarded message -------
From: "Yves Lafon" <ylafon@w3.org>
To: "Philip Jägenstedt" <philipj@opera.com>
Cc:
Subject: Re: on grammars and parsing algorithm
Date: Thu, 04 Nov 2010 16:41:38 +0100

On Thu, 4 Nov 2010, Philip Jägenstedt wrote:

> On Thu, 04 Nov 2010 14:24:32 +0100, Yves Lafon <ylafon@w3.org> wrote:
>
>> Hi Philip,
>> I think that we are not that far form reaching agreement, we are just  
>> seeing things form a different angle and need to reconcile on that,  
>> mostly.
>> Grammars can serve two purposes, creating automagically non-forgiving  
>> (and fast) parsers, but it also defines what "normal" content should be.
>>  There is also the famous Postel's law "be lenient in what to accept,  
>> strict in what you send".
>> Grammars define the "be strict in what you send" part, and there was  
>> always some fuzziness in what "be lenient" means. What I understand you  
>> want is a strict definition of what "be lenient" means, so a consuming  
>> algorithm.
>>  The crux of the issue is that grammars can also get into the  
>> "consuming" side of it. So how about defining the parsing algorithm  
>> precisely, including error recovery, and make that normative. AND  
>> having the grammar also normative, but clearly stating that it defines  
>> the syntax producers should follow, not consumers.
>> Would that, in your mind, solve the issue ?
>> Cheers,
>>
>
> Would it be OK to have this discussion on the list?

Sure, you can forward your response (or I can do it if you prefer)

> What you suggest in the last paragraph would be fine in principle, I  
> know of other specs (HTML5, WebSRT) that have completely separate syntax  
> and parsing. For MF, the parsing would be something like the algorithm  
> that is in section "D.1 Processing name-value components" of the current  
> draft. However, making that normative seems to be unpopular in the  
> working group, which is why I tried to make it smaller and simpler in my  
> latest version..
>
> In our case, it is really only in parsing the generic name-value pairs  
> that lenience is needed. When parsing the dimension formats (like NPT),  
> we can simply refer to the ABNF. As long as there can be no doubt about  
> what implementations should do I'm not too fussed with the details, but  
> of course I think we shouldn't make things more ugly than they need to  
> be and the spec no larger than it needs to be.
>
> Let's continue discussing specific proposals on the list?
>
>


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 4 November 2010 15:48:04 UTC