- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 28 May 2009 13:07:00 -0700
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On Thu, May 28, 2009 at 12:22 PM, Roy T. Fielding <fielding@gbiv.com> wrote: > On May 28, 2009, at 3:17 AM, 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 saw it. I suggest you do a little more research on the term, > because Larry is about thirty years ahead of you on that. > See Interlisp. Links are a lot more useful than simply suggesting to "do a little more research". I spent a little time trying to find information about an Interlisp interpreter that is different from the kind of interpreter than what Maciej was referring to, but didn't find anything easy to digest. Links would be helpful. And while I agree that Maciejs definition of the word interpreter seems narrow, I'm also unaware of something consuming markup languages ever being referred to as an interpreter. >>> 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? > > All of them. CMSs, maintainers, validators, mash-ups, help systems, > refrigerators, switches, and televisions, just to name a few. Is the fact that the HTML5 spec defines exactly what is valid HTML5, and thus when an error occurs enough for these? Or do we need to add additional text to the spec to support these types of HTML processors/implementations/whatever? >>> Hence, there should be one specification of the language >>> in terms of syntax and declarative semantics (that applies >>> to all applications) and separate specifications of behavior >>> during application-specific processing of HTML. >> >> I continue to disagree, and I once again point out that things are not >> generally done this way for other languages, even other W3C languages. > > My bookshelf disagrees with your opinion. Even the compiled languages, > which have very limited application-specific behavior, are always split > into separate sections for tutorial, reference (complete syntax/semantics), > and application-specific behavior (e.g., differences between architectures > that have 16, 32, or 64bit words). Note that these are books, not > standards specs. The standards are just the reference section. Straw man. First of all no one here has claimed that tutorials shouldn't be in a different document than the HTML5 spec as far as I know. At least not in this thread. Second, the spec already have different section the semantics (currently sections 3-5) and syntax (secion 9) as well as application-specific behavior (section 6). / Jonas
Received on Thursday, 28 May 2009 20:08:04 UTC