Issue76

Keep Microdata

The following is the counter proposal for ISSUE 76

Editor: Tab Atkins Jr. (jackalmage@gmail.com)

Please address feedback to the HTML Working Group mailing list (public-html@w3.org).

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. The editor of the HTML5 spec has publicly indicated that he believes it to be more efficient to have a single spec rather than multiple separate components. HTML is also much easier to reference if it is contained within a single document.
• 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.
• Microdata is not a uniquely independent technology bolted onto HTML5. It is as much a part of the language as any other extension mechanism in HTML5, such as @class, @id, @title, etc..
• Removing sections from the HTML5 spec until they are 'mature' is not part of the development model of the HTML5 language and has never been. Once something is established as a provisionally good idea, and is mature enough that a spec for it can be written that is expected to solve real use-cases adequately, it is put into the HTML5 specification, and left there unless it is later decided to be a bad idea or unimplementable, in which case it is dropped. This method has been successful so far, and there is nothing special about Microdata that would suggest changing this approach. As well, Microdata is relatively mature when compared to certain other parts of the HTML5 spec that are not being considered for separation/removal. It solves well-defined use-cases and is expected to be easy to implement interoperably.
• 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; removing sections from a specification in Last Call is purposely simple.
• 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.
• While it is true that either RDFa or Microdata (or both) may fail in the marketplace, we should as a working group give the most support to the technology we most believe should succeed in the marketplace. We should support technologies that do not rely on syntaxes that are known to be very confusing to authors, such as namespace prefixes; we should support technologies that do are simple to use, rather than having multiple ways of doing similar things; we should support technologies that are simple to implement quickly and that authors can easily use correctly.
• 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.
• Microdata, as written, would not be reusable by other technologies even if located in a separate spec. Its processing model is designed specifically to make its use in HTML simple and natural. Reusing it in, for example, SVG would not be possible, as SVG lacks a element, a <meta> element, uses a different technology for linking resources, etc.. Generalizing Microdata so that it could be used in technologies such as SVG would make it much less useful for HTML, and it would still be less useful for these other technologies than it could be. It is, however, relatively simple to see how to design a parallel technology to Microdata that is specialized for a particular other language.
• If Microdata were to be split from the HTML spec, it is possible that control of it would move to a separate working group, which would move part of HTML's development out of the hands of the working group chartered to develop HTML.

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.