ebXML can help speed up the Government Online architectural effort

Whereas most international standards bodies traditionally advance with all the speed of the great tree sloth, the advent of ebXML — and its companion standards — comes as somewhat of a surprise. By comparison, its emergence has been lightning-fast, relatively clean and exceptionally promising. While everyone but the most ardent developer or document management specialist may have to resist the temptation to initially think of ebXML as little more than “tags on steroids,” this is not the correct perspective. The important issue is that ebXML lets you create any kind of document or ‘’object” with virtually any kind of hierarchical content definition which any machine — or human — can easily read. Thus, ebXML does more even than what ASCII did for data exchange — combined with what UNIX did for application portability. XML is descended, in part, from SGML, which is a major tagging language used to “mark up” documents with descriptive tags. At McDonnell Douglas we used SGML to mark up the total body of aircraft flight manual and maintenance manual information (in one mega-document) for the MD-11 trijet airliner in such a way that we could create customized manuals reflecting only the precise equipment installed on a given operator’s aircraft. For example, MD-11 aircraft were offered with both GE and Pratt&Whitney engines and a given operator’s manual would of course only cover the precise engine variant which they had specified. This document would thus be created by including only the material between a specific desired sets of tags and ignoring all of the other material. The ebXML effort has extended and optimized the linguistics and syntax of XML to permit the nesting of infinite numbers of tiers of classes or taxonomies. Among other things, this allows different organizations to define things using different terms yet still be able to conduct business easily with each other. For example, a British and an American car company could work together and one could use “hood” while the other used “bonnet” and these would be automatically cross-translated in transactions going in either direction.
ebXML, despite all its advantages, creates some risk of instituting a form of “government-by-tablet” within whatever commercial, governmental or institutional realms it is used. Depending on the realm, and the participants’ expectations, that may or may not be a problem. Solutions are possible, but we need to recognize the problem and deal with it. While there is little question that ebXML can help accelerate the Government OnLine architectural effort, we must not fall into the trap of simply worshipping what business thinks, says and does is a perfect analogue for what government does.
The business of government is a vastly extended subset of the business of business. The GoC must implement this technology in the best interest of the Canadian people, even where this means modifying or departing from the way in which business is planning to use it for its own benefit. This dictum must apply as much to ebXML as to any other technology.
Further, I predict that the battle over whether to merely take ebXML in its current form as gospel and immediately implement it exactly as recommended, versus also demanding something more, will be the largest and most emotional techno-political battle since the advent of commercially viable open systems at the beginning of the 1990s, a development actively contested by every proprietary vendor and many public sector IT people.
At that time there was a cat-fight among the UNIX System V.4 and OSF advocates.
Previous GOC leadership contributed directly to the single Unix standard as we know it today.
So public sector action indeed can influence the direction of privately and institutionally sponsored standards-making and specification-writing activities — even in the middle of a standards war.