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

On Jan 12, 2010, at 8:34 AM, Julian Reschke wrote:

> Hi,
>
> in last week's telco, ISSUE-79 was mentioned as something that needs  
> a change proposal. While talking about this, Larry also mentioned DC- 
> HTML, which also brought us to @profile (ISSUE-55).
>
> Here are a few thoughts:
>
> ISSUE-27 <http://www.w3.org/html/wg/tracker/issues/27> ("rel  
> ownership")  is about a registry for @rel values, currently in  
> progress. Hopefully Mark Nottingham's changes in <http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt 
> > will bring us closer to a common, non-HTML specific registry.
>
> That being said, there's a related issue for registering values for  
> meta/@name, currently specified similarly to link/@rel (using a  
> WhatWG Wiki). I believe this issue has been forgotten somehow --  
> does it need a tracker issue? The next steps for ISSUE-79 somehow  
> depends on that.

I think it would be acceptable to propose a registry as a Change  
Proposal for ISSUE-79. If anyone plans to do that, I think it would be  
reasonable to grant an extension until after the ISSUE-27 deadline.  
That being said, I think a Change Proposal for ISSUE-79 would not  
necessarily need to tackle the registry issue, it could just propose  
the specific new meta value.

If anyone wants to take up the issue of how the meta/@name registry is  
handled directly, I believe the proper first step would be to file a  
bug.

>
> 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.

> 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.

>
> Going back to the HTML5 spec:
>
> "Conformance checkers must use the information given on the WHATWG  
> Wiki MetaExtensions page to establish if a value is allowed or not:  
> values defined in this specification or marked as "proposed" or  
> "ratified" must be accepted, whereas values marked as "discontinued"  
> or not listed in either this specification or on the aforementioned  
> page must be rejected as invalid. Conformance checkers may cache  
> this information (e.g. for performance reasons or to avoid the use  
> of unreliable network connectivity)." -- <http://dev.w3.org/html5/spec/Overview.html#meta 
> >
>
> I note that validator.nu does not implement this. Maybe this  
> indicates it's hard to do? Minimally it shows that this requirement  
> hasn't really been tested in practice.
>
> Finally, regarding DC-HTML:
>
> This was originally defined in RFC2731, nowadays in <http://dublincore.org/documents/2008/08/04/dc-html/ 
> >. It defines how to transport DC (and other) metadata in meta  
> elements, using head/@profile to opt in, and link/@rel to define  
> prefix mapping. For instance,
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
>   "http://www.w3.org/TR/html4/strict.dtd">
> <html>
>  <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
>    <title>Services to Government</title>
>    <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" >
>    <meta name="DC.title" content="Services to Government" >
>  </head>
>  <body>
>  </body>
> </html>
>
> This markup will be invalid HTML5 because of
>
> a) the removal of head/@profile,

This is covered by ISSUE-55.

>
> 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.

>
> c) because of the use of unregistered meta/@name values.

This does not seem to be tracked, as you pointed out above.

>
> A potential replacement for DC-HTML would be either RDFa or  
> Microdata, but I'm less than enthusiastic to have another extension  
> format becoming invalid which is in use.
>
> Feedback appreciated,

I have made some suggestions above about possible bugs to be filed.

Regards,
Maciej

Received on Tuesday, 12 January 2010 16:43:04 UTC