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

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.

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.

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

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,

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

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

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,

Julian

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