Evolving Standards

I’ve been trying to finalise this post for a long time now, but today’s publication of an HTML5 draft that includes a new microdata section makes it all the more relevant. The long and short of it is that I am less and less concerned about the huge mess that is the HTML5 standardisation process. On the one hand, it’s a huge mess; on the other, it doesn’t matter.

I’ve been thinking about it this way: the web is an ecosystem, a rich, complex and ever-changing environment in which HTML documents live alongside browsers, developers, Javascript, CSS, spiders and robots and so on and on.

Every HTML document is like a creature living in this ecosystem. If you study the documents, you discover species and families and genera. Some may be like nautiluses — throwbacks to earlier eras when browser wars raged and nested tables were acceptable ways of laying out a page, but all the documents that you can GET are managing to survive in this modern environment in their own ways.

The kinds of documents on the web have evolved over time, as new browsers, legal regulations, and development practices open up new ecological niches. The documents we see now on the web are a snapshot that reflects that evolutionary process and the current web ecology.

What we know from the natural world is that the best way to survive in such an environment is to gradually adapt. In the natural world, the genetic make-up of an organism determines its survivability, and the mixing and mutation of genes allow organisms to react to changing conditions. The corollary to genes in the web world are elements and attributes. Some are evident across multiple organisms, essential parts of the way the web works (<p>) while others are only present in the rarest of specimens (<dir>). The elements and attributes that a page uses determine its utility to a large extent: who can view it, how its content can be processed.

What is the role of standards bodies in this rich, complex and ever-changing environment? They are like geneticists: documenting and manipulating genes in the hope of improving the survivability (utility) of the documents they effect. And only the kind of mad, hubristic geneticists you see in B-movies would attempt to

  1. make large genetic deviations from known working organisms
  2. commit specicide (there will always be an ecological niche for successful organisms)
  3. create organisms that cannot evolve (because those that cannot adapt will die)

Translated to the web, I predict:

  1. Creating grand new designs for HTML will not work (witness XHTML2); instead, it will develop through a series of small, gradual adjustments.
  2. HTML5 cannot hope to eliminate the use of any particular markup (such as RDFa), if it’s useful for even the smallest population. Introducing an alternative that satisfies those same requirements in a better way might cause some change but the legacy will never completely die.
  3. Even if HTML5 is not defined to be extensible, documents will be created that extend it to meet requirements we don’t even know about yet.

So, long term, I’m not worried. The web will evolve and there is space enough in it for us all. Short term, it’s a pity that so many intelligent, thoughtful and engaged people are wasting so much energy on a conflict that can’t be won.

Comments

Re: Evolving Standards

I pretty much agree. This is why HTML5 is being designed as evolutions of HTML4 rather than a big overhaul (indeed, we keep punting things that people suggest to HTML6 or beyond, to avoid succumbing to too serious feature-creep).

I don’t think anyone wants to eliminate RDFa, eRDF, Microformats, ruby, <marquee>, <blink>, or any number of other extensions to HTML. Some of them (e.g. the drag and drop model Microsoft invented for IE) eventually get adopted as core parts of the language, others (e.g. <ruby>) get simplified, adapted and included, yet others (<marquee>, <blink>) get replaced by features in other languages (e.g. CSS).

BTW HTML has a number of extension mechanisms, for details please see the FAQ entry on extensions in HTML5.

HTML6, 7, 8 will continue extending HTML in the directions we need.

Re: Evolving Standards

I agree, and I don’t.

With the change to remove property from the HTML microdata proposal, we can continue to use RDFa, albeit invalidly, with X/HTML5.

However, I’ve been looking at the triples that Philip is generating from the microdata proposal examples. The graph described when using eRDF or RDFa does not match the graph generated by Philip’s application. Not only that, but triples are generated yes, but they don’t necessarily reflect the underlying RDF model.

But what happens if something like SearchMonkey adapts to consume microdata, assuming that it can do as RDF triples and merges the data into its data stores? If there is no robustness to the microdata implementation, if all we care about is “it can generate ‘RDF triples’” then potentially we could have a polluted data store, which would then impact on all of us.

It’s about the same as cutting rain forests in Brazil, and burning coal for energy in China—we can do our own thing, but whatever good we may do, could be effectively damaged by the harm others do.

Re: Evolving Standards

I’m happy to adjust the conversion-to-RDF algorithm if it needs fixing — send an e-mail to one of the lists, or to me directly (ian@hixie.ch) telling me what needs changing (and why), and I’ll see what we can do.

Re: Evolving Standards

No, I won’t.

You threw this proposal into the spec. You did. There’s no guarantee, at all, this will stay in the spec. In fact, every indication it won’t.

So, why, on earth, are we spending time on something that is just as likely to vanish in a few weeks?

Re: Evolving Standards

It’s true that sending feedback today might be premature. Waiting to see whether we decide to keep this or not before sending feedback is very reasonable.