- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 16 Aug 2010 21:52:39 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: David Singer <singer@apple.com>, Ian Hickson <ian@hixie.ch>, public-html@w3.org
Maciej Stachowiak, Mon, 16 Aug 2010 11:16:11 -0700: > On Aug 16, 2010, at 2:54 AM, David Singer wrote: > I found these pieces of information notable, because: > > (a) The suggestion of an additional/parallel HTML-specific link > relation registry is not in line with the current ISSUE-27 Change > Proposal, which calls for using the IANA registry exclusively (so > perhaps now is a good time to call for alternate proposals). > > (b) Given the above pieces of information, it seems that the current > ISSUE-27 Change Proposal, if not revised, could have significant > normative impact beyond just the registration mechanism for link > types. It would interest me to hear in what way you foresee this "significant normative impact". Care to explain? The most important - and unsurprising - info I have heard is that the Link Registry wants to be a registry for stable relations. Whereas Ian wants a "live" registry that "matches reality". (I follow the link registry list - I did not pay much attention to the "diary" that Ian posted here.) The point with the registry is, I think, that it should document link relations that are the same everywhere. Thus it is supposed to document _that_ reality. This puts a pressure on link type specifiers to define language unspecific relations: once defined, one cannot change a relation only in order to match reality in just one of the languages/specs where the relation is useful. Despite that Julian says that is not hard to send register a relation, I think another purpose with the registry is to make sure that the energy spent on defining link relations, can be reused also in other specs etc. By the way - Bug 7475 is exactly about this: Ian wants to change some relations. He even admits that the changes he suggests are dramatic: [1] "the definitions in HTML5 rock the boat". Whereas I and some others wants to maintain the relations as defined in HTML4, XHTML1 etc stable. Neither authors or implementations should experience that link relations changes meaning under their feet. That said, not all link relations needs to be the same everywhere. HTML5 could define a link relations profile: If you use HTML5, then you also accept only the HTML5 profile as valid. Via the profile attribute - supported by extensions to HTML5 and in other HTML dialects - one can anyhow override any link relation semantics. Of course: only in those UAs which support profile. Thus, in practice, not really ... Which again calls for stable and shared link relation semantics. However, the @profile thing demonstrates that not everything need or can be in the registry. But also: Not everything in the registry needs to be in HTML5. I think it - long ago - is too late to make <!DOCTYPE html> become a kind of versioning signal which signals that some link relations will be interpreted differently when using that doctype. At best, HTML5 could make some link relations forbidden in HTML5 documents - without changing their meaning. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c5 -- leif halvard silli
Received on Monday, 16 August 2010 19:53:15 UTC