Re: [whatwg] [mimesniff] An alternative approach to section 9 of Mime Sniffing

I had no particular problem reading the spec -- I even wrote an 
implementation of some parts of the sniffing algorithm -- but if I were to 
write the spec myself, I would have used ABNF myself.  Now I see that ABNF 
is not necessarily the best approach here.

As a side note, I have noticed that specifying both a grammar and a parsing 
algorithm for the same syntax in the same document can cause practical 
issues in implementation, especially when both are treated as normative and 
not merely one of them [1][2]. (This should not be taken as suggesting 
changes to the MIME Sniffing or WebVTT specifications.)

[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22103
[2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22104

-----Original Message----- 
From: Gordon P. Hemsley
Sent: Saturday, May 25, 2013 3:38 AM
To: Peter Occil
Cc: Anne van Kesteren ; WHATWG
Subject: Re: [whatwg] [mimesniff] An alternative approach to section 9 of 
Mime Sniffing

Section 5 is highlighted with all that red warning stuff precisely
because it is known to be incomplete and insufficient. I haven't yet
decided how I'm going to go about writing that up (and it isn't
inherently obvious that what is there now is bad). So that's not the
best example; and it certainly doesn't have anything to do with
section 9 (at least, not with regard to formatting).

I still don't understand what problem you're trying to solve (and if I
don't understand the problem, I can't come up with a solution). Are
you just having trouble reading and understanding what's there?

MIME Sniffing and WebVTT have very different usecases and, in some
ways, very different audiences. I don't think you can directly compare
the two.

Gordon

On Sat, May 25, 2013 at 1:58 AM, Peter Occil <poccil14@gmail.com> wrote:
> What I think is that even if an ABNF won't be the normative definition of 
> a
> syntax format, it can help put the format's syntax into a higher-level
> perspective and aid understanding of its syntax: once we understand, for
> example, what the Content-Type header field value ought to contain, in the
> form of an ABNF or in some other way, it will be easier to write 
> processing
> rules for that field value in the spec.  (Right now I'm in the process of
> rewriting section 5 of the MIME sniffing spec.)
>
> Take the WebVTT spec for example.  For each part of the WebVTT format
> there's a definition of what that part contains in terms of characters, 
> and
> the actual processing rules for parsing that part.  For example, the
> definition for "WebVTT cue timings" and the algorithm to "collect WebVTT 
> cue
> timings and settings." The definition aids understanding of the syntax for
> WebVTT cue timings and informs how the rules for collecting WebVTT cue
> timings are written in the WebVTT spec.
>
>
> --Peter
>
> -----Original Message----- From: Anne van Kesteren
> Sent: Friday, May 24, 2013 1:28 AM
>
> To: Peter Occil
> Cc: WHATWG
> Subject: Re: [whatwg] An alternative approach to section 9 of Mime 
> Sniffing
>
> On Thu, May 23, 2013 at 2:49 PM, Peter Occil <poccil14@gmail.com> wrote:
>>
>> Explain further why you don't recommend ABNF for this case.
>
>
> We don't recommend ABNF in general because often ABNF results in a
> mismatch between prescribed and actual processing. E.g. Content-Type
> is defined as an ABNF and technically "text/html;" does not match that
> ABNF, but everyone (logically) processes that as "text/html" without
> parameters.
>
> It's much better to define the actual processing so implementers are
> less inclined to take shortcuts when implementing (test suites also
> help, but they're typically written way-after-the-fact).
>
>
>> You should also explain whether another change to make section 9 more
>> readable is
>> appropriate (though it currently is relatively readable as is).
>
>
> I'll leave that to Gordon.
>
>
> --
> http://annevankesteren.nl/



-- 
Gordon P. Hemsley
me@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/

Received on Saturday, 25 May 2013 10:24:41 UTC