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
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?
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.
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.
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.)
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.
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.
Thus far we've seen that there are hazards of using standards, and that they shouldn't be used blindly. There are undeniable benefits of using standards, however, but a strong self-interest should be your guide. So let's look at the positive aspects of being selfish. There are many advantages of "rolling your own," despite the stigma of wheel reinvention. Also, there are times when not doing so makes sense, too.
Nobody knows your business better than you. It's essential when planning to have control over as many variables as possible. If you want to start delivering information to your customers in XML format you might be faced with the choice of waiting 6 months for a standard to be completed, and associated reworking of your systems, or to define document structures that meet your business needs straight away.
There has to be a convincing case above and beyond altruism to risk your business with standards developed by third parties. The two main reasons to do this are when it's useful for creating new business or when it will cut costs. Needless reinvention is as stupid as blind adoption.
Economics aside, developers have a strong interest in the good design of a system, which can be jeopardized by external dependencies. It is possible that standard technologies may not have a good design or that their future development is not guaranteed to happen in a sane way.
If you know you can do something better, and it doesn't affect your business adversely, then ignoring the standard makes a lot of sense. On the other hand, if you have to adopt a standard, be sensible about the way you do it.
How much the adoption of a standard affects you depends on how you design your systems in the first place. The inherent instability of most XML standards means that it would be hazardous to the long-term health of a system to build it around the standard itself. Instead, it would seem sensible to always build around models of your own business data and processes.
We must understand that business is the strongest driver of standards, not technology. Consequently, it seems folly to let somebody else's business make decisions that directly affect your own. Reserve the ability to interface with standards, but don't take them into the heart of your own strategy. If you must become strongly involved, then you should also become involved in the development of a standard.
One of the hazards of systems development is over-specification: that is, anticipating future requirements and overcomplicating a system to fulfill them. In many situations, those future requirements will never actually arise. The Extreme Programming people call this "Big Up-Front Design" (BUFD).
The antidote to BUFD is to build only what is necessary and retain the ability to change a system to respond to varying needs. For instance, a firm manufacturing widgets might be concerned about the ability to conduct business using technologies established as a result of the ebXML project. It might want to take this into account when developing an internal system. By any reckoning, such a scenario is probably two years off. A sensible policy would be for them to use such XML technologies as fit their immediate needs, but to be aware of the broad requirements of electronic order fulfillment, and make such provisions as are necessary not to make this cost prohibitive to implement at a later date.
In the current economic environment, few can guarantee consistent levels of market or funding over the next six months, and even "short" periods like two years seem a long way off. Doing the least necessary work but preserving the ability to change makes more sense than ever.
The effects of BUFD are also felt within standards themselves. The more traditional approach to standards are that they're distilled from long-term agreement on particular aspects of a technology. ANSI C is a good example. However, many of the standards we must now contend with in the XML world are more like inventions-by-committee, lacking the assurance of being tried and tested. By the nature of their creation, they are extremely vulnerable to over-specification.
Several such standards have withered due to not addressing popular requirements or else have entered into a second generation of adjustment in the light of experience. In either case, there are costs inherent for those who adopted early. Developers should feel justified in picking and choosing carefully.
Also in <taglines/>
If everyone adopted the cautious self-centered approach mentioned above, might we never have had XML in the first place? Plainly, this selfish policy that I've outlined isn't directed at visionaries or missionaries. But the large majority of the developer community is not out to change the world. Most developers are out to get paid so they can feed themselves.
In fact, XML's essential qualities allow the selfish policy to succeed. By using XML 1.0 and namespaces, you've already made a large commitment to interoperability with others and assured yourself of future flexibility. In most cases, simple transforms will be enough to enable you to fulfill relationships with external parties. XML's major benefits are to be reaped on the outside, not the inside, of a system.
It is vital to understand that XML is not a platform, however much companies would like to market it as one, and that it's entirely possible and very sensible to use as much or as little as you need. The benefit of XML is that it has provided a way to exchange data in a decentralized way, where individuals can retain control over their destiny. Clearly this runs counter to the dominant inclinations of large corporations, who would like to recover their advantage by tying more and more into XML, and making it into an all-or-nothing platform.
A selfish -- some may prefer pragmatic -- policy is entirely in line with using XML. It may well benefit you to adopt XML, and reap the benefits of interoperability and flexibility, but there was and is nothing about XML 1.0 that mandates the recentering of strategy to blindly follow standards bodies. Standards should be made to compete, and present tangible benefits to their adopters, and not be the insidious mechanism of those seeking control.
I will end by highlighting the major recommendations for pursing a selfish policy of XML development, and I certainly welcome and encourage discussion and feedback in the forum below.
Spend time understanding your own needs
Don't turn off your critical faculties because something's a "standard"
Pick and choose what suits your needs
Don't tie standards into the core of your systems
Reserve the option to change your mind later