Re: Registries, meta/name=keyword, head/@profile (ISSUE-27, ISSUE-55 and ISSUE-79)

Maciej Stachowiak wrote:
> ...
>> Looking at <http://wiki.whatwg.org/wiki/MetaExtensions>, I see:
>>
>> "Process
>>
>> For the "Status" section to be changed to "Accepted", the proposed 
>> keyword 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".
>>
>> For more details, see the HTML5 specification."
>>
>> But, as far as I can tell, the HTML5 spec itself doesn't specify the 
>> process. That appears to be a bug.
> 
> That seems like it's worth filing in bugzilla too.

<http://www.w3.org/Bugs/Public/show_bug.cgi?id=8727>

>> With respect to the proposed process: a W3C specification seems to be 
>> a *very* high bar; do we really want that? (Is this another bug to be 
>> raised?).
> 
> I could imagine either filing this separately (hopefully with a concrete 
> proposal for what standard to use instead), or it could be part of the 
> same bug that suggests a meta/@name registry.

There's the related issue that the bar for meta/@name appears to be much 
  higher than for for @rel, which doesn't make any sense to me. But due 
to ISSUE-27 that might be changing.

With respect to meta/@name: whatever the procedure is exactly, it should 
allow non-W3C members to define a new value, and it shouldn't be 
necessary to have a W3C Working Group for this. Is there a publication 
process inside the W3C that allows this?

> ...
>> b) the current text about the validity of unregistered link relations 
>> (DC-HTML uses a prefix for the relation, so it would need to define a 
>> wild card), and
> 
> This is presumably covered by ISSUE-27; the registry would be the proper 
> venue to register DC-HTML link relations.

Not really, as DC-HTML uses a prefix/localname notation inside the @rel 
value. There *are* matching URIs for the link relations, so what would 
be needed is HTML5 allowing full URIs without registration as link 
relations.

> ...

Best regards, Julian

Received on Thursday, 21 January 2010 14:59:59 UTC