« Podlinks | Main | HTTPLR draft-01 published. Some background. Some futures. »

How long would it take to move Mount Fuji?

Dabid Megginson is ruminating on XML Namespaces, and concludes:

"It's too late to change Namespaces now"

I'm more upbeat that things can be changed once we know better. In XML Namespaces, default namespaces and attribute scoping are something of a problem in the trenches. Addressing them is not going to be a case of meddling with the infrastructure so as to reap no benefits. I imagine they cost the industry no small amount (just think how many developer-hours have been expended on SAX2 namespace processing alone).

How would we go about changing something when it's too late to change? There's no quick fix, no magic bullet, but there are 3 things that come to mind:

  • Stop the rot. Call out what has gone on before as an anti-pattern. Indicate that no technology will be executed in that manner in future. Have zero tolerance. One of the issues with XML today is that while there are conversations about the merits of various parts of the puzzle going on within the XML world, there's a lack of ruthlessness in clearly stating what people should not be doing across the industry. It might have been risky to do this 4 or even 2 years ago, but XML is so well-established now, actively identifying, cataloguing and eradicating anti-patterns does not put its continued adoption at risk. Quite the opposite.
  • Establish what should be done instead. Define the best practice and evangelise it. For example with namespaces, this might be to always use prefixes or to always have acceptance criteria that your markup be easily and soundly embeddable in other markup. Elliotte Harold's Effective XML is a good place to start as are the IETF guidelines, and both need to be continually updated. The Reach RIG documents are also valuable guidelines, as much for the explicitly articulated process of evolution through subsetting as the technical specifics.
  • Clean up your legacy. I take my cue from the agile mode of thought here. When you are surrounding by broken windows, and being surrounded by broken windows is costing you, you fix them one at a time until you are done, or until you have fixed enough windows that there are no more broken ones being added. On the face of it such work often seems impossible (hence the title of this entry being "How long would it take to move Mount Fuji?"), but that's only if you take it as one big job to be done. Software after the fact is long lived, and most programming is maintainence programming - but you will have to apply triage as to what parts to fix nonetheless.

To be clear on this, no-one should expect that the writers of a specification can see all eventualities and consequences of their work. So when I say there's a problem, it's not apparent to me that anyone could have forseen back in 1998 or earlier, that a dominant use of XML would be as an enveloping and packaging technology for messages and protocols, which is where these issues tend to bite hardest. One way to obsolete a software technology is to suggest it cannot evolve. So on the balance, I think it's worth keeping the option to change XML+Namespaces open.

In short, never say never - things can always be made better. XML+Namespaces as of 2005 is a local maxima not a frozen accident.


March 12, 2005 08:00 PM

Comments

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1490

Listed below are links to weblogs that reference How long would it take to move Mount Fuji?:

» Required Reading: "No Silver Bullet" from pbblog
Via Charles Miller, a link to Fred Brooks's classic essay, "No Silver Bullet". (You can also get it at the IEEE Computer Society, here.) As a small advertisement, here's a quote: "I believe the hard part of building software to be the spec... [Read More]

Tracked on March 12, 2005 11:43 PM