- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 12 Jan 2010 08:42:26 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "public-html@w3.org" <public-html@w3.org>
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