W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 26 Aug 2009 05:49:35 -0400
Message-ID: <4A95052F.8080602@intertwingly.net>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
Roy T. Fielding wrote:
> On Aug 25, 2009, at 7:28 PM, Ian Hickson wrote:
> 
>> On Tue, 25 Aug 2009, Roy T. Fielding wrote:
>>>>
>>>> No, by definition, every HTML5 implementation has, or must act like it
>>>> has, a DOM. The DOM is used in HTML5 as a model used to describe what
>>>> implementations must do even if they don't actually expose the DOM in
>>>> any black-box testable way.
>>>
>>> Hence my objection to how HTML5 has been defined in terms of DOM
>>> operations, which are neither present in nor understood by the vast
>>> majority of implementors of HTML.
>>
>> The overwhelming majority of implementors of HTML are very familiar with
>> the DOM concept. It's fundamental to CSS, scripting, and many aspects of
>> HTML itself. It's more or less equivalent to the concept of an Infoset,
>> which is similarly used as the basis of many XML specifications.
> 
> The DOM state as an infoset, yes.  HTML5 is not defined in terms of
> the DOM state.  It is defined in terms of operations on that state
> (i.e., behavior), including attributes of the DOM that are a side-effect
> of processing operations.  The difference is quite huge.

I'm going to try to recap my understanding; which may very well be 
significantly imperfect, but perhaps if you both can point out where I 
veer off into the weeds, it might be useful in furthering discussion.

First premise: there exist elements in the language that are widely 
discouraged (whether that is deprecated, obsolete, non-conforming, or 
whatever is immaterial to this particular discussion).  An example of 
such is the <plaintext> element.  However, even for such elements, it is 
important that the spec completely describes their behavior, and that 
conforming user agents have no observable behavior that differs from the 
behavior specified.

Second premise: there exists (in the past, present, and foreseeable 
future) HTML implementations that not only do not possess a DOM, they 
positively have no interest in possessing a DOM.  Within the scope of 
the functions that they perform, all that is important is that they do 
not differ in observable behavior from other implementations that may 
possess a DOM.  If they do that, such implementations can fully 
interoperate and participate in the ecosystem that we call the web.

I don't believe that either of these premises are in dispute, but I 
welcome anybody to indicate otherwise.

Now, let's try to anchor (no pun intended) the discussion with a 
concrete example expressed in terms of a HTML fragment:

   <table>
     <tr><td>foo</tr>
     <a name='bar'>x
     <plaintext>
     <a name='baz'>z

In that fragment, the behavior that HTML5 describes is that there exists 
exactly one anchor, and for any implementation for which it is important 
to define the precise location of that anchor, the correct placement is 
before the <table>.  Any implementation that can be observed to behave 
differently (e.g., ones that identify two anchors, or ones that identify 
the anchor as being placed within or after the table) may be of some 
utility, but can't be described as fully interoperable or conforming.

And I will note that all of the statements in the above paragraph are 
independent of the fact that the above fragment is itself non-conforming 
in a number of ways.

Now, expressing the full interoperable behavior desired in this case is 
a daunting task.  As a matter of editorial style, Ian has often chosen 
to define such behaviors in terms of the info-set that a DOM-possessing 
implementation would produce.  On matters of editorial style, people can 
and do differ, but as long as the document produced does not run afoul 
of the second premise above, the document may not be considered ideal by 
all, but it is acceptable.

Returning to the topic at hand, we are discussing a media type 
registration.  However imperfect or incomplete the current Working Draft 
may be at this point in time, I do believe that the common intent of 
this Working Group be that the Recommendation that is ultimately 
produced be consistent with both of the above two premises.  We've had 
orthogonal discussions on what's the best way to update the media type 
registration, and those discussions seem to have reached a resolution.

So where are we?  I believe that we are well on our way to closing issue 
53, though during the course of the discussion we may have identified a 
related issue, namely the concern that the current Working Draft does 
not contain the detail needed to enable non-DOM producers or consumers. 
  I would be hesitant to open an issue on that, however, in that it 
doesn't appear to be obvious how to identify those points of contention. 
  Specific bug reports would instead be much more productive.  It does 
occur to me that areas of the spec which describe obsolete or 
non-conforming markup are ones where a more careful review may be in order.

If I got any thing wrong, please let me know.  My only hope that this 
furthers the discussion.

> ....Roy

- Sam Ruby
Received on Wednesday, 26 August 2009 09:50:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:44 GMT