Re: "index" link relation (ISSUE-118)

Tantek Çelik, Thu, 23 Jun 2011 14:03:17 -0700:
> On Thu, Jun 23, 2011 at 13:47, Leif Halvard Silli wrote:
>> Tantek Çelik, Thu, 23 Jun 2011 12:03:59 -0700:

>>> In short:
>>> * if a rel value was in a draft and is missing (without explanation)
>>> from the final spec, or
>>> * if a rel value was in a previous version of and is missing (without
>>> explanation) from an update to the specification (even a draft update)

Above you use the phrase "(without explanation)". I was reading this as 
"with or without explanation". May be that was incorrect? Are you 
really trying to find "explicitly" made decisions?

It  is obviously correct to observe that some link relations are not 
inside HTML5. But you jump to conclusions if you make anything more out 
if it that.

The thing is - or was - that the Editors' definitions of those link 
relation keywords were contradicting with previous specifications, 
including Micorformats's definitions. Therefore it does not make sense 
to say that those link relations were remove. 

What was removed was some keywords, and the interpretation/definiation 
of those keywoards. 

Attempt at explainging what happened: If Microformaats has maintained 
that 'foo' means 'bar'. And then up comes Ian and says that 'foo' 
should mean 'bam'. And then comes HTMLwg decision and removes 'foo', 
what is it that then has been removed? Is it 'foo' and 'bam' or 'foo' 
and 'bar'? 

E.g. let us take "index", which the Editor defined as a synonym for 
"top". Not a single spec defines 'index' as synonym for 'top'.  Thus, 
the "explicit dropping" of 'index' happened becasue there were 
fundamental disagreement in the WG about what 'index' was supposed to 
mean. 

Would it not be very sad - and flawed -  if the Micrormats community 
dropped 'index' because the HTML5 editor happened to create FUD about 
its interpretation? 

(It might be that the HTML5 editor's arguments should be considered by 
the Microformats community. But then he should raise them for the 
community.)

Just take a look at your own table, it says that 'index' = 'Refers to a 
document providing an index for the current document.' Then compare 
with the - fortunately - obsolete HTML5 interpreation, in which 'top' 
was synonymous with 'index', 'toc' and 'contents'. No spec has, to this 
date, operated with these keywords as synonyms.

You may want to inspect the overview that I pointed to in my CP, for an 
overview of the different interpretations, including the Editor's: 
http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html


>> A repeatable, objective criteria: HTML5 doesn't per se decide what goes
>> into the Microformat registry. Rather, it is the opposite way. The
>> Microformats registry is supposed to be the one which forms the basis
>> for whether a link relation may pass the door to the HTML5
>> specification.
> 
> cite/link to HTML5 spec text or WG decision text that supports this
> "supposed to be" assertion?

First citation: 
http://lists.w3.org/Archives/Public/public-html/2011Apr/0204.html


]]  the HTML Working Group hereby adopts the "Defer to the
Microformats community for cataloging HTML rel values" [[

If deferred to the Microformats community, then it does not make sense 
to defer it back to the HTMLwg by citing a HTMLwg decision. The 
Microformats community has freedom disagree with the HTMLwg. And, at 
the very least, it should inspect an evaluate the arguments, and not 
assume that may have been a useful HTMLwg decision is a useful link 
relation registry decision.

The Microformats community should independently review the link 
relations if it is supposed to be the HTML5 link relation catalog.

Second citation:  
http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html 

]] No objection explained why registration as extensions was 
insufficient, and such registration would allow more time and freedom 
to fine-tune the definitions of these relations, independent of the 
HTML WG.

Decision of the Working Group

Therefore, the HTML Working Group hereby decides to adopt the proposal 
to drop support for rel="" values based on the lack of interest from 
implementors and users. [[


>> Finally, my CP, which was the reason why it became an issue, did cover
>> more than the 3 link relations you have listed as officially rejected.
>> And, AFAICR, all of them were "dropped" from HTM5.
> 
> It's your responsibility to register them per the process.

(And yours.) 

What I was pointing out is that you have not completed what you purport 
to have completed. You purport to have removed what the the working 
group decision "dropped". But actually you haven't. The Editor's 
check-in comment, which is the result of the the comment by Maciej that 
you were linking to, is useful reading in that regard: [1]

]] Drop support for rel=up, rel=last, rel=index, rel=first, **and any 
related synonyms**. [[

And, if you scrape the stricken section of that check-in, then you end 
up with these 10 keywords (which according to the pre-decision draft - 
and no other draft in this world - represented only 4 relations 
http://www.w3.org/TR/2011/WD-html5-20110113/links.html#links), that 
were dropped from HTML5:

"first":
01    first = 1st relation
02    begin = 1st relation
03    start = 1st relation

"index":
04    index = 2nd relation
05      top = 2nd relation
06      toc = 2nd relation
07 contents = 2nd relation

"up"
08       up = 3rd relation

"last":
09      end = 4rth relation
10     last = 4rth relation

If you are meant to be consequentical, then you should delete all those 
ten link relation keywoards, because they were all explicitly dropped.

But I don't want you to drop them. I simply think that 
your/Microformat's reference to HTML5 should be dropped. And that you 
should not treat them as dropped in any way. If the HTML5 editor wants 
to redefine these keywords, then he should take it up with the 
Microformats community.

(May be I am misunderstanding what you mean by "dropped". But my 
interpretation is that this means that you will simply reject those 
keywords if they come up.)

If the Microformats community simply drops these keywords due to that 
HTMLwg decision, then you have in reality accepted the *obsoleted* 
interpretation of those keywords.  Because: Ian had two Change 
Proposals. One proposal was to keep the definitions he had made for 
these keywords. However, that proposal did not win. What won was the 
his proposal to remove those keywords. So, in order to implement the 
HTMLwg decsion, you should simply accept that there is no new HTML5 
definition of these keywords. And the Microformats community must look 
somewhere else for a definition of them.

[1] http://html5.org/tools/web-apps-tracker?from=5923&to=5924

-- 
leif halvard silli

Received on Thursday, 23 June 2011 23:20:42 UTC