- 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