Re: Re: on grammars and parsing algorithm

On Fri, Nov 5, 2010 at 2:48 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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?
>>
>>

Would it make much sense to have a "production rules" grammar
(basically what's there) and a separate "parsing approach" section,
which can be a combination of grammar & the current appendices?

Silvia.

Received on Thursday, 4 November 2010 21:29:53 UTC