W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2010

Re: Re: on grammars and parsing algorithm

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 5 Nov 2010 08:29:00 +1100
Message-ID: <AANLkTimJPcHDWbmNAbhTw8=TPfbZOHU__oK=ymx1HT8t@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>
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?

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC