XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

The Selfish Tag

The Selfish Tag

October 24, 2001

All is well in XML Arcadia. Hardworking, honest coders use XML without fear of complications, safe in the knowledge that the esteemed guardians of standards have carefully and painstakingly anticipated their every need. Before embarking on a project, everyone is sure to take advantage of existing work, ensuring maximum interoperability with each other. ASCII and ISO Latin 1 are but dim memories, as nobody would even think of using anything but Unicode. Each new stride forward in XML standards brings an increased efficiency to the world, and greater mutual understanding blossoms, accompanied by an enormous sense of well-being.

This delightful vision of the XML world sounds both familiar and infeasible. Familiar, because it's the theme song of software marketers everywhere -- if you want, replace "XML" with "web services", ".NET" or "Java". Infeasible, because a moment's reflection tells us that life's not like that at all.

The most critical choice facing people developing systems that use XML is normally which particular XML technologies to use (and by this I mean not only processing APIs such as SAX or XSLT, but also document types such as RDF or SVG). Do you choose an existing standard, or do you develop something that fits your purposes?

There are many arguments for and against using third-party standards, and to some extent they mirror the decision of a developer to use an existing toolkit or roll her own. Many of the advantages and pitfalls are similar.

Table of Contents

Reasons to be Selfish, Part One

Uncertain intellectual property situation
Standards swayed by those involved
Imported bloat
Uncertain intellectual property situation

Reasons to be Selfish, Part Two

Retain control
Standard is not the same as well-designed
Leave it until later
Retain control

Reasons to be Selfish, Part Three

The Selfish Manifesto

Now we've had a few years of XML development, it's clear that the path of open standards is not a simple one. Despite the obvious argument in favor of open standards -- e.g. avoiding unhealthy commercial domination of data storage or transmission formats -- it's plain that blindly hitching up to everything going just because it's a standard is not a sensible policy.

The current received wisdom has corrupted the desirability of open standards into the notion that the developer is helpless and must wait for standards to emerge before progressing. In fact much criticism of XML is based on this misconception, that somehow if you choose to use XML 1.0 you're immediately beholden to anything that emerges from W3C, OASIS, or others.

Is it possible to pursue a self-centered approach to XML development, while preserving those advantages which arise from apparently altruistic collaborations in standards development?

Reasons to be Selfish, Part One

Let's start out with reasons to consider a selfish approach to XML system development; especially, reasons to be wary of standards. Throughout this article, I'm mainly writing with W3C and OASIS-led standards in mind, as they're largely the most relevant to the XML community.

Uncertain intellectual property situation

How do you know that by using a standard you won't get stung for royalties? It's happened before with Unisys and the LZW patent that affects the GIF image format, and it'll happen again with other standards. Altruistic adoption of a standard only works if all parties agree to the same levels of cooperation. As long as there are patents, there'll always be this risk.

The intent of the W3C's new patent policy seems to be at the very least to make this plain a priori, in order to remove the uncertainty from the situation.

Standards swayed by those involved

A more subtle effect of certain standards is that they may be geared towards bolstering the business of particular participants. In fact, this is almost always true, otherwise it is hard to see why the participants would get involved in developing standards. Even if a standardized technology isn't blatantly supporting the business of the participants, it is likely to have been influenced by the political interests of the participants.

In the XML world, XML Schema provides an example of this. When XML Schema was getting started, everyone was very afraid that Microsoft would not participate and instead continue to pursue their own XML schema technology, XDR. It stands to reason that Microsoft's cooperation meant that there's a commercial advantage for them in participating (this holds for Commerce One and other companies who already had a financial interest in XML schema languages). Thus an important core technology, XML Schema, started not from an unbiased position of considering what would be the best solution to the problem, but from a position of political compromise. The end result of XML Schema is a difficult technology that more or less mandates the use of commercial software to use in the first place. (Yes, there are open source validators, but the design of XML Schemas is ridiculously difficult to do by hand.)

Imported bloat

By their very nature, standardized technologies support a wide variety of requirements. They're almost certainly more than you need. Adopting them means several things. First, time spent on learning about the technology in order to judge its utility. Second, adoption means either implementation (or import) of technology to deal with more than you need or a conscious decision to not implement what you don't need.

Comment on this article Share your experiences of developing with XML standards in our forum.
Post your comments

The learning curve issue is important. Many technologies promise increased convenience yet hide the costs of learning how to use them. This is true in the world of computing platforms: you're offered an environment where a basic level of functionality is implemented for you, but you pay the cost of learning that platform -- a cost which often leads you to be tied to the platform due to the cost of re-orienting. An analogue in the XML world right now might be SOAP: you get increased convenience in that you need to write less message-handling code, but you've unwittingly imported a dependence on deep, as yet unresolved issues, such as the interaction with firewalls and caches.

So, from the selfish point of view, simple and old standards are a much safer bet than complex or new ones.

Pages: 1, 2

Next Pagearrow