Re: HTML interpreter vs. HTML user agent

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.

>> 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.

>> 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.

I already did.

>> If the title applies only to browsers, then the applications
>> that are not browsers are not bound by its requirements
>> beyond their need to interoperate with browsers.  Consensus
>> here would then be reduced to a more tractable problem.
>
> The whole point of the spec is to enable interoperability,  
> including among different classes of implementations. I can't think  
> of any piece of useful HTML-processing software that has no need to  
> interoperate with either browsers or existing deployed HTML content  
> on the Web,  at the very least through some chain of indirection. I  
> suppose you can imagine completely closed ecosystems of HTML where  
> the content is never authored using a standard tool, or consumed by  
> a standard browser, search engine, mail client, assistive  
> technology, etc. But I don't think it is worth it to make a  
> separate spec to cater to such walled garden use cases. Inside a  
> walled garden you can do whatever you want, regardless of specs.

Straw man.

>> 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.

....Roy

Received on Thursday, 28 May 2009 19:23:08 UTC