- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 08 Dec 2009 11:42:04 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, public-html <public-html@w3.org>
Thanks for providing a Change Proposal for this issue! The chairs are reviewing Change Proposals to ensure that they meet the required structure. Here is our feedback on this Change Proposal: (1) This Change Proposal meets all of the formal requirements. We have separately suggested updating this Change Proposal in response to discussion. Regards, Maciej On Dec 2, 2009, at 3:37 PM, Tab Atkins Jr. wrote: > Per Maciej's request, since we're having trouble with the ESW wiki, > here's my change proposal, so that we have a version in w3c-space that > can be pointed to and archived: > > Counter-Proposal for Issue 76 - Keep Microdata in the spec > ========================================================== > > Summary > ------- > This is a counter-proposal to the current Change Proposal for Issue > 76, intended to support keeping Microdata in the current HTML5 spec. > It is positioned both as a general (though not exhaustive) argument in > favor of keeping Microdata in the spec, as well as an answer to > specific arguments in the current Change Proposal. > > Rationale > --------- > > * All good specs which integrate with HTML5 should, ideally, be a part > of HTML5. Inclusiveness promotes greater attention to each part, and > ensures that the language evolves in directions which are most > helpful. A spec which is separate from HTML5 may find the easiest way > to resolve difficulties is to route around them, rather than altering > or extending the HTML language itself, which may be the best option > overall. > > * A spec that is designed within HTML5 and one designed outside of it > are qualitatively different (see Conway's Law). One designed > originally as part of the larger spec tends has a larger "surface > area" alongside the rest of the spec, rather than limiting its > interaction to a small number of channels. This makes it harder to > separate out (though Manu has already done that work) and makes it > more vulnerable to incompatible changes in the larger spec. Something > which originated within the spec is best kept within the spec or > dropped entirely; it should require strong reasoning to separate it > out. > > * Many parts of HTML5 cannot be considered 'mature' and are in fact > actively changing, and yet are still part of the spec. It is expected > that these sections, Microdata included, will receive implementation > attention and experience, and will be amended or dropped as these > experiences warrant. Lack of maturity is not a reason for removal of > any other part of the spec, and there is no distinguishing feature of > Microdata that would warrant it being treated differently. > > * Microdata does not appear to be in an extreme level of flux to > warrant concerns of it holding up HTML5's progression in the standards > process. If it turns out to indeed limit the main spec it can be > split out at that time, but at the moment this is nothing more than a > theoretical concern. In the other direction, it does not seem likely > that implementations of Microdata will progress any quicker if it was > a separate spec, and so HTML5 cannot be said to be slowing down > Microdata's progress either. In the event that Microdata does fail in > the marketplace, it can simply be removed from the spec at that time; > there does not seem to be any benefit in spending effort to make this > action any simpler. > > * The purpose of the W3C is to advance the web, not to remain neutral > in technological conflicts. If one technology under the W3C's purview > is better than a competing technology, it is our responsibility to > actively decide in favor of it. To do elsewise would be dereliction > of our core duty to the web. Microdata and RDFa are directly > competing, as they accomplish virtually precisely the same thing; > there is no good reason to use both on a page except for gratuitous > proliferation of metadata embedding syntaxes. > > * The Microdata data model is extremely simple for simple, common > cases, and is complex only in rare, complicated cases. Its tree-based > nature (as a set of nested name/value pairs) matches well with both > the HTML language and XML and JSON data storage/interchange formats. > The processing model is extremely simple and well-defined, and > essentially trivial to implement. The DOM API associated with it > makes retrieving metadata from a page via a script in the page > extremely simple, broadening the possible usages of Microdata beyond > spiders and the like to actually being useful in applications. It is, > in short, a simple and intuitive metadata syntax in a field where > neither adjective can typically be applied, backed up by user studies > that directly informed its design. Removing it from HTML5 would > provide no benefit to authors or implementors, and would likely serve > only to slow down the development and deployment of a useful tool for > authors. > > Proposal Details > ---------------- > The Microdata section of the current HTML5 spec remains in the spec, > and is not split out into a separate spec. > > Impact > ------ > By keeping Microdata in the spec, we encourage more eyes and feedback > on it. Experience has shown that attention paid to spin-off specs is > much lesser than when they were a section of the main spec. As well, > we would be promoting a simple, useful solution to demonstrated > existing use-cases. This will allow machine-readable data in general > to get where it needs to be faster than if Microdata were split out. > > ~TJ
Received on Tuesday, 8 December 2009 19:42:38 UTC