[whatwg] Rel and META values

On Thu, 2 Jul 2009, Jeremy Keith wrote:
>
> I'm a bit confused by the conditions set out at the bottom of the rel
> extensions wiki page:
> http://wiki.whatwg.org/wiki/RelExtensions
> 
> "For the "Status" section to be changed to "Accepted", the proposed keyword
> must either have been through the Microformats process, and been approved by
> the Microformats community; or must be defined by a W3C specification in the
> Candidate Recommendation or Recommendation state. If it fails to go through
> this process, it is "Rejected"."
> 
> 1. Should I change all of the values derived from XFN from "proposal" to
> "accepted" as they seem to fit this criteria?

Sure.


> 2. I don't think passing the buck to the microformats community is 
> necessarily a good idea. There are perfectly good values listed (e.g. 
> rel="accessibility") that would/should probably never become a 
> microformat but are still good semantic values. Will they really be 
> rejected outright?

The goal wasn't so much to pass the buck, so much as to grant them power. 
However, I personally would be fine with another solution also. All we 
really need is a core group of strong-minded people who are willing to own 
this problem and maintain this list responsibly (saying no to most 
proposals, demanding rigorous specs for those they accept, preventing 
duplicates, documenting existing practices and implementations, etc).


> Then there's the wiki page for META values:
> http://wiki.whatwg.org/wiki/MetaExtensions
> 
> "For the "Status" section to be changed to "Accepted", the proposed keyword
> must either have been through the Microformats process and been approved by
> the Microformats community; or must be defined by a W3C specification in the
> Candidate Recommendation or Recommendation state. If it fails to go through
> this process, it is "Unendorsed"."
> 
> This is kinda nuts. No META value will *ever* become a microformat; the 
> very concept of invisible metadata is anathema to microformats?it's 
> impossible for a META keyword value to pass the microformats process.

W3C specification it is, then. :-)


> Should everything on the wiki page be marked as "unendorsed" or, more 
> realistically, should the conditions for acceptance be altered?

Both, probably. But I don't have a better proposal so far.


On Wed, 15 Jul 2009, Bil Corry wrote:
>
> I'm curious too, since the HTML5 draft itself says[1]:
> 
> -----
> "This specification does not define how new values will get approved. It 
> is expected that the Wiki will have a community that addresses this."
> -----
> 
> So the verbiage at the bottom regarding how a status becomes "Accepted" 
> appears to be incorrect.  There is no process currently in place to 
> adopt any proposed rel value as Accepted.

The "community" right now is defined as the microformats+w3c communities. 
I'd like a more dedicated community, but that doesn't just happen on its 
own -- someone has to step forward and own that process. It's a lot of 
work, and if we are to have continuity and stability in the process, it 
would have to be someone willing to commit to this for many years.


> The other issue is Mark Nottingham's Web Linking draft[2].  It section 
> 6.2, it establishes its own Link Relation Type Registry and the process 
> by which additional link relations are added.  It would seem to me that 
> it would be prudent to have a single registry and process for both HTML5 
> and the Web Linking draft.

Web Linking isn't really compatible with the HTML5 spec as far as I can 
tell. For example it doesn't let you create types that depend on the other 
types present (e.g. as we do with "up" and "alternate"), it doesn't let 
you add other attributes (as we do for "icon" and sizes=""), it doesn't 
define how the linking fits into the processing models for other 
technologies (e.g. where style sheets from Link: headers fit in to the 
cascade), and so on. Mark is aware of these issues, but has declined to 
make his draft handle them. At the moment, HTML5 doesn't hook rel="" into 
the Web Linking registry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 19 July 2009 03:39:40 UTC