- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 28 May 2009 09:15:11 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Maciej Stachowiak wrote:
>
> On May 28, 2009, at 12:52 AM, Roy T. Fielding wrote:
>
>> HTML application = {HTML interpreter, HTML generator}
>
> Please see my post on this thread for why the term "HTML interpreter" is
> inaccurate and grating.
>>
>> I think it is useful to distinguish them. I don't think
>> this has anything to do with the user agent terminology.
>>
>> OTOH, I do agree with your underlying points. The fact is
>> that different applications of HTML will have very different
>> operational behavior, particularly in the presence of errors,
>> so a specification that defines HTML in terms of operational
>> behavior of just one type of implementation is broken for all
>> applications that don't happen to be of that type.
>
> What kinds of HTML processors/implementations/whatever have different
> requirements and would have different behavior in the presence of errors?
>
>> That's why the title of the document matters. If the title
>> applies to all HTML applications, then the specification must
>> define HTML in a way that is suitable for all applications.
>
> The spec is meant to apply to any software that generates or processes
> HTML. Some requirements are scoped to particular conformance classes. If
> you feel it does not do so, then please describe how, rather than
> debating the title.
+1 to a request for "identifying very different operational behavior".
Once that is done, we can reasonably proceed to decide whether the front
matter or the body of the document needs to change. Until then, what we
seem to have is a situation where some believe that the body will
eventually be made consistent with the title and abstract, and others
see that it currently is not consistent.
A concrete example is feed sniffing, where the operational behavior of
feed readers is very different than the operational behavior of
browsers. If this section is eventually split out, then the issue (with
respect to "HTML 5: A vocabulary and associated APIs for HTML and
XHTML") goes away. If, however, it ends up remaining, it needs to be
identified clearly as operational behavior of one type of application,
and not part of the vocabulary and associated APIs that all applications
need to implement.
Anybody care to identify any more specifics?
- Sam Ruby
Received on Thursday, 28 May 2009 13:15:46 UTC