Preventing standards death march, plus augmenting RELAX NG to support variants

By Rick Jelliffe
February 11, 2009 | Comments: 12

ISO standards can, at committee request, be marked stable, which means they are not expected to change. That this is not the default may be surprising to some people, especially if you have some kind tablets of stone view of standards.

In the particular cases of OOXML and ODF, I think there is a strong need to find maintenance models that are both workable, don't disenfranchise their champions, give all stakeholders an equal voice, and prevent death marches. I suspect ODF and OOXML are both very prone to the death march (i.e. where a project just drags on, swamped by feature creep and committee paralysis.

I suggest there are two important practical issues, apart from the organizational behaviour of committees.

Schedule releases

The first is that I think the ODF and OOXML standards should move to a strictly timed release cycle. So ODF 2009, ODF 2010, ODF 2011, OOXML 2009, OOXML 2010, and so on. (ISO standards are already year stamped.)

At a particular deadline point in the year, all the maintenance items agreed to in the committee would get collected and rolled into a new version. Note I wrote agreed to: very typically committees choose the route of closing off new items for discussion, but sometimes items take years to resolve, which leaves any urgent and uncontroversial items waiting, pending resolution of the others. It becomes a waterfall process, with all the characteristic pathologies which waterfalls are prone to.

Such a regularly stage schedule would make life more predictable for vendors and their development cycle (OK, every year we schedule a service pack) and users (This fix was decided three years ago, why isn't it fixed in the standard yet?), gets fixes out faster, and also reduces the problem of bundling diverse fixes into a single ballot result.

Variants

The second thing that can help is for schema languages to support variants and evolution with first class constructs. Schematron's phase mechanism lead the way here, but I see no reason why grammars might not usefully have some other kind of mechanism.

For example, here is a possibility for RELAX NG: this could be implemented by a macro pre-processor of the schema, or combined with the language. Lets use the compact syntax: the idea is to allow two functions as particles in content models: true() and false(). (If the () notation is no good, then something else could be found.)

So that allows a pattern like the following:


book = element book {
title,
( true(), subtitle)?,
( false(), author)?,
section*
}

The logic would be interpreted so that these content models resolve to

book  =  element book {
    title,   
    subtitle, 
    section* 
}

Just using the built-in pattern definition mechanism, we can then have


has-subtitle = true()
has-author=false()

book = element book {
title,
( has-subtitle, subtitle)?,
(has-author, author)?,
section*
}

or


version-2008 = true()
version-2009=false()

book = element book {
title,
( version-2008, subtitle)?,
( version-2009, author)?,
section*
}

Then, we allow patterns (on the condition that they only are true() or false()) to be specified in the command-line, overriding pattern values in the schema.

This gives us, in effect, a boolean conditional language. Dave Peterson was advocating that SGML needed something like this in the mid 1990s: I suppose that the variant issues that SGML DTD faced after 8 years or so of the release of SGML is similar to the problems we face now with schemas, 8 years or so after the release of XML and XSD.

This gives the ability to capture various different schemas in a single language, which makes the history of the changes more explicit.


You might also be interested in:

12 Comments

Rick I agree. Standard organizations and the specifications that are produced by these organizations need to become less waterfall like. At STAR we have adopted Agile development techniques and methodologies for producing our standard. We produce an official version once a year for general consumption, and members get access to Milestone and Draft releases throughout the year. We even have the ability to produce nightly realses of all repository artificats include guidelines. Standards development can be more agile, it just takes the willingness to change by the members and participants.

Rick, I'm not aware of any markup standards which have annual revisions. Can you suggest 3 or 4 examples as models for this?

It might work in some cases, in some industries, for example a standard that must track regulation or other business rules that change annually. But for an office document standard I think it is more natural to track the typical release-to-release interval of office applications, which tend to have major releases every 3 or so years.

Also, keep in mind the process overhead at consortium and JTC1 levels. If an approval cycle takes 9-14 months combined, annual releases are not going to happen.

As for death marches, how long exactly have we been waiting for DSDL to be completed? Since 2001? I think the two years we've been working on ODF 1.2 pales in comparison.

David: Thanks for the example. For readers who are not aware, STAR is the Standard for Technology in automative Retail. http://broadcast.oreilly.com/2009/02/preventing-standards-death-mar.html David is also an O'Reilly/XML.COM blogger.

Rob: If the question is whether standards organization's rules allow this, then certainly for ISO (and every other org I know) there is no procedural problem. Indeed, I recently heard a suggestion that a three month(!) amendment cycle would be best, to have a continual pipeline to respond to the market, and so that voting was more targetted.

[Also, remember that ISO in particular has a strong requirement that corrigenda get addressed in a timely fashion. So these (sometimes minor fixes, sometimes typos, sometimes hopeless SNAFUs) get accepted and published independent of any major version plans. ISO standards are already numbered by year, so yearly seems reasonable.]

Examples? Why is there any requirement to repeat the mistakes of the past? I can certainly name several standards where an open-ended collection process lead to a death march: indeed, XML grew out of the SGML death mark (the "five year revision" that was no where near completion after 10 years), XSD took forever, and I am sure you have been very frustrated by the delays in ODF 1.2. When you know you have a death march, relying on the poor project management of other standards is unnecessary.

Three year cycle? Microsoft may have that (and they also have a service pack systems), but if we look at OpenOffice (the Wikipedia page has a box on releases) we see a minor update (e.g. the n in m.n.v numbers) of 16 months, 10 months, 4 months, 2 months, 10 months, 13 months, 12 months, 3 months, 6 months, 6 months, 7 months. (http://www.cyrius.com/journal/2007/03/16#openoffice has some different numbers.)

The Wikipedia entry on OOXML says:
"As of the 2.0.3 release, OpenOffice.org changed its release cycle from 18-months to releasing updates, feature enhancements and bug fixes every three months.[9] Currently, new versions including new features are released every six months (so-called "feature releases") alternating with so-called "bug fix releases" which are being released between two feature releases (every three months)."

Indeed, Eric Raymond's Cathedral and Bazaar even has a section called "Relase Early, Release Often."

The trouble with the "fit in with major release cycle" approach (which is what I used to think was a reasonable approach) is that the more a standard is implemented or used by different applications and stakeholders, the less equitable or proper it is to tie things to a single product's development cycle.

So are you saying that standards groups should pick one implementation, and then time their release cycle around it? Are you going to nominate KOffice's release cycle? Are you really saying that it is OK if IS29500's update cycle should exactly follow MS Office, and that IS26300's update cycle should exactly follow OpenOffice? Surely not!

Rob #2: There is no requirement for one amendment cycle to finish before the next one starts at ISO, especially where the amendments or revisions cover different groups. Hence the comments about waterfall.

On the topic DSDL, do I sense some hostility?

The major parts of DSDL (Part 2, 3, 4) have been finished for years, and in widespread use, and indeed we are working on revisions. The minor parts have taken longer, and indeed we have cancelled two parts (well, in the case of the validation framework we are waiting until W3C gets XProc finished --and they are being very 'thorough'-- and in the case of complex integrity constraints it became clear that we should wait until the market/bazaar coughed up the technology and champions. ) But it is a multi-part standard; parts can come and go depending on market/bazaar requirements.

That is the nice thing about non-monolithic standards.

Rick, I think you misunderstand Raymond with respect to Release Early, Release Often. He is talking about Linus's early practice of having nearly _daily_ releases of the kernel. He's talking about realtime co-development, stimulating the community with new stuff continually, like a morphine drip.

And remember this was from the pre-commercial days of Linux, when the users and the community were the same and early release of the code and early release of the product were the same thing. It isn't that way today. But we can still release code early and often, do frequent developer builds, etc., while maintaining a level of stability in less frequent distro updates.

Standards development bears little resemblance to this process. We're obviously not going to release versions of a standards on a daily basis. A closer analogy would be to post frequent drafts at very short intervals (compared to typical ISO speeds), say weekly, to stimulate the community. But you would still want to have less frequent releases of the approved standard itself, since the release and adoption of a standard serves as a synchronization point between producers and consumers. In other words, neither of us care if you and I are using different versions of the Linux kernel. But we should care if we are using different and incompatible versions of HTTP, HTML, SMTP, etc.

Rob: Pretty much every standards group has, sooner or later, a death march problem. At its most severe, it shows up as paralysis where no change to a standard is possible (the long-term lack of internationalization of domain names is an example that comes to mind).

And there is also a problem that when a new version of a standard requires too much work to support, developers are reluctant to support it. Smaller, targetted changes may be more doable, especially for the small open source contributer.

If a committee prefers a three-year major release cycle for a particular project, that is fine. The issue is how to prevent this stretching into, say, a five year death march. I think even with a three year major release cycle, regularly scheduled yearly maintenance releases would still be useful.

The standards world tends to be very slapdash with its scheduling, in ways that would never be acceptable for software engineering. The release of a new version of a standard is a kind of crisis where all the implementers have to figure out whether they want to follow the new version or not. Moving to a more regular model where there are dependable milestone releases would make life more predictable for developers.

One of the troubles with ad hoc release cycles is that very often a committee will evaluate a feature request and say "We will do this in the subsequent version" (such as ODF 1.3 etc.) In effect this says "You will have to wait at least 5 years with no guarantee". A snaller, more regular release cycle would be more responsive to market needs and provide a better story for committees that decide to defer some decision from the immediate next version.

Let me be cynical. ISO Maintenance may be not essential in the strict sense. I understand that all standard consultants want the public to believe otherwise. The only purpose of having ISO standard adoption is the stamp. As Tim Bray put it concerning ISO-OOXML: "And just like your mother told you, when they get what they want and have their way with you, they’re probably not gonna call you in the morning."

If I want the public sector to adopt OOXML or ODF as their default format they don't care much if it is 1.0 or 1.3. Right now they embrace ODF without too much regard of contents and virtues because they know it it an open standard they trust. In a law you even find the "format of Openoffice". In reality governments will operate with "1.5" documents or in the case of OOXML Microsoft their pptx, xlsx, docx files. Despite that ISO OOXML has really earned a bad reputation and its official endorsement by a government agency would get people to yell at your administration, so you would better ask them to support docx than OOXML.

The standard consultant objective of maintenance and the commercial objectives differ. Maintenance is just pro-bono. How would it affect public adoption if ISO stamps 1.2 in 2015? From my experience I would argue, not at all. It is more like a Debian release, if it gets released it is also irrelevant.

In a strict ISO cult sense the situation may be different. The irrelevance of ISO is dictated by their slow process.

André: If the purpose of the standards is branding, then you are right. If the purpose of the standard it to allow interoperability, you are dead wrong. The ISO process is a nagging dog, demanding maintenance and allowing inconvenient issues to be raised and hard questions to be asked if there is interest.

Indeed, maintenance is a litmus test for whether the proponents of "interoperability" for each standard were talking complete crap. Interoperability is all about how the gaps (between versions, implementations, extensions) are handled in the least toxic ways.

I don't see how people can have it both ways: claim that the ISO process is inadequate then not even meet its standards!

By the way, where does 2015 come in: are you saying you don't expect OASIS ODF 1.2 until 2014. That would really be a death march.

ISO did not approach OASIS to make ODF a ISO standard, OASIS approached ISO. Ditto for ECMA and OOXMLM. And an ISO standard requires maintenance and scrutiny.

Why is maintenance a "standard consultant issue"? It is interesting that you pit "standard consultant" against "commercial interest" rather than "users" against "vendors". Maintenance is an interest for all stakeholders and we need to find ways to make the process and the implementability pallattable for the broadest range of stakeholders.

Rick and et al.: The problem here is the same thing that Agile development methodologies face when being introduced to software development. The feeling that their process is unique, and that doing it in iterations, and releasing early and often can't be done. Agile development can be applied to standards development, it takes a willingness of those doing the development to be willing to change the way they do it. Only develop for what you know now, not what might be needed in the future. Automate the build and publishing of the standards, implement where possible unit testing if you are producing a grammar no matter what format that is. Prioritize the backlog, set a development cycle of 4 weeks or less. Release Milestones for review, set a release candidate cycle. At STAR we have proven that this can be done. In most cases it's the process that needs tweaking and a willingness for those developing the standards to change.

I wrote a paper a while ago addressing this title "Agile XML Schema Development" and it can be found at:

http://www.starstandard.org/STAR/XML2006

BTW, slight correction the blog is at http://intellectualcramps.blogspot.com.

No output of a process with a long or deep engagement graph can release early and often without causing apples to fall off the cart. It is precisely a complexity challenge where the dependencies determine the degree of noiselessness.

In human terms, it really depends on what you care the most about. Stimulating a community and irritating members are the same thing.

There is no cult of ISO. There is a cult of 'we are smarter and faster and entitled' and it has nothing to do with any particular organization. It is a cultural phenomenon with inexperienced parties on one end and slightly devious and occasionally disgruntled parties on the other end who have in common the trait that feathering their own nests is far more important than the community outcomes.

Pick a side but remember, the empty side (don't play) is always a member of the set.

RELAX NG already has the proposed feature.

has-subtitle = empty

has-author= notAllowed


book = element book {
title,
( has-subtitle, subtitle)?,
(has-author, author)?,
section*
}

Murata: I had missed that! Great! That opens up some exciting possibilities.

(The standard has no natural language describing the operation of . I think we should look at this.)

News Topics

Recommended for You

Got a Question?