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

On Aug 25, 2009, at 4:03 PM, Ian Hickson wrote:

> On Tue, 25 Aug 2009, Roy T. Fielding wrote:
>> On Aug 24, 2009, at 10:13 PM, Ian Hickson wrote:
>>> (For instance, above, you use the word "defined" in a way that is
>>> completely at odds with my understanding. A feature is fully
>>> "defined", as I understand it, by the combination of authoring and
>>> implementation conformance criteria, which we have for <a name>, yet
>>> you do not consider it to be "defined".)
>>
>> I use "defined" as it is found in any English dictionary. The only  
>> thing
>> HTML5 draft defines related to <a name> is browser behavior in  
>> response
>> to a fragment retrieval request, which may be sufficient for a  
>> BROWSER
>> that is limited to performing view operations.
>
> This is incorrect.
>
> HTML5 defines how "name" is to be processed as part of the  
> HTMLCollection
> object for any implementation that includes DOM APIs, and the  
> definition
> of the meaning of fragment identifier syntax for text/html  
> documents, for
> any HTML processor.

http://dev.w3.org/html5/spec/Overview.html#the-indicated-part-of-the- 
document

    If there is an a element in the DOM that has a name attribute whose
    value is exactly equal to fragid (not decoded fragid), then the  
first
    such element in tree order is the indicated part of the document;
    stop the algorithm here.

> No mention of browsers is made in any of these conformance critiera.

1) I don't have a DOM (only browsers do).

2) I am not trying to determine "the indicated part of the document";
    I am trying to find errors (possibly due to combining the input
    of more than one content part) in a generated document.  In order
    to do that I need to know the meaning of the mark-up, not the
    behavior of a browser when traversing a DOM.

3) the above algorithm is wrong -- most of the elements in HTML that
    have name attributes are not valid destinations for hypertext
    links and any browser that actually follows that algorithm would
    break existing content if the anchor name happens to be something
    commonly used in non-anchor name attribute (like "keywords",
    "content-type", "author", "edit", etc.).

What you are saying is that I have to rely on all prior definitions
of HTML (that were not written in this insane browser-centric style)
in order to figure out the meaning of mark-up in "text/html".
Fine, so the issue is resolved by listing all HTML specifications
as being definitive for "text/html" and I'll just choose the one
that explains the language in my terms.

> In that case, I completely disagree with your world view of how
> specifications should work.

That much is obvious.  It does not, however, make you the ultimate
decider of whether an issue is valid or not, or whether the content
of the current draft resolves that issue.  Consensus is not found
in the eye of the editor.

....Roy

Received on Tuesday, 25 August 2009 23:46:20 UTC