The Extensibility Manifesto

by Rick Jelliffe

The Extensibility Manifesto is not the latest Robert Ludlum novel but a movement, spearheaded by respected industry figure Dale Waldt, well-known as a publisher of the <!TAG> newsletter for many years in the 90s: <!TAG> was what the SGML industry did for information before XML.COM came along. The Extensibility Manifest shares a lot of the mindset of The Agile Manifesto, for example the need to protect against over-engineering and out-of-controlness.

I've been happy to sign up to it, because I think it addresses some really practical gotchas. At first glimpse, the ten points to the manifesto may seem a little managerspeak-ish: how much leveraging can a poor boy take, after all? But it is aimed at mananagers, who can use it to check their XML production processes, practices and environment.

Turn the points into questions or a checklist. So "1. Schemas and data have a mutual obligation to the simplest structure possible, achievable by continual reassessment of the two by their creators and rigorous justification for every modification." becomes
  • How are we making sure our schemas and data have the simplest structure possible?

  • Do we have a process or procedure in place for reassessment of structures (refactoring, etc)?

  • Do we have a process or procedure in place to state, adjudicate and log justifications?

These are all very practical questions, and address the evil triplets of early XML deployment: incompleteness, inflexibility, and over-engineering.

My company, Topologi, has been fairly quiet this last year both because of my indisposition and because we have been re-aligning our developments to fit in with the Extensibility Manifesto. A point like 5. Effective sampling and analysis upfront reduces risk and improves implementation schedules clearly raises the question "How do we do efficient sampling and analysis?": the metrics I recently blogged about fit in there, clearly (as do Topologi's utiliites.) Like the Agile Manifesto, the Extensibility Manifesto is a kind of meta-benchmark: you don't get certified according to it (like ISO 9000) but an organization can adopt it as way to prove that XML processes align with business requirements.