- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 24 Jun 2011 01:20:01 +0200
- To: Tantek Çelik <tantek@cs.stanford.edu>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org" <public-html@w3.org>
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