For many years, supporters of various XML standards have been discussing which standard is the ultimate all-embracing ‘super-standard’ that is of course much better than all the others. But does such a 'super-standard’ even exist? And do we even need such a ‘super-standard’? I want to examine these questions in the following article.
XML in the past and present
When we started using XML for Technical Editing – a field led by the military and aviation industry – a lot of pioneering work was necessary. The aim of the first XML application for military and aviation purposes was actually to standardise sources. The plan was to combine content packages from the makers of various sub-systems into one manual.
And they succeeded admirably. But they did have perfect conditions: The market was dominated by a few manufacturers, and they agreed that nobody should be able to supply systems without complying with the standard. So low-level sub-contractors were forced to give in to pressure from the major manufacturers.
It was different in other industry sectors. Small system providers would often buy products from major component manufacturers. The introduction of XML proceeded at a fairly slow pace for more than 10 years and continues to this day. Again and again there have been calls for a consistent standard as used in the military and aviation industries. But there is still no such standard. There have been several more or less successful attempts, which have yielded the DocBook, MUMASY, PI-Mod and DITA standards. In addition, nearly every system manufacturer has its own standard. And many companies have either modified these standards or developed their own. So we now have a global landscape of XML structures that is the opposite of standardisation: uncontrolled growth.
Varied requirements
Why is that? There is no scientific study into this topic (interesting though it would be), but an exclamation quickly emerges when you consider the facts. First, there is no pressure exerted by a few major customers; but the main reason is most likely that different companies have different requirements for the creation process, within the editorial office. These differences are clear:
- bulk goods vs. individual production
- small part vs. major system
- variant-specific configuration vs customer-specific development
- marketing affinity vs. technical practicality
- industry specialisation vs. generalist usage options
- software vs. hardware
- and much more
The range of requirements is as wide as the product range of all manufacturers worldwide. That means that the ‘super-standard’ that applies to everyone may not even exist. And this fact is reflected in the continuing discussion about standards. One person’s ultimate solution is the next person’s pile of rubbish. So there is no such thing as “the XML standard”, just one that is more suitable than others in a specific situation.
The way things are going, the basic concept of suppliers providing XML data in creation format that manufacturers can then process and integrate into their documents seems to be moving ever further away. And maybe that is not even what we actually want. After all, what we want to do during the creation process is to work in the best possible way instead of letting others talk us into their various ideas; what we (probably) all want to do is to provide our end customers with user information that is as informative as possible, that contains no breaks that are detectable to the user, and that contains all the information, whether created by us or brought in, so that it is easy to access and find. Either way, I believe that user information should be a lot more than just a collection of PDF files from suppliers.
But to achieve this we do not have to exchange source formats. And nobody really wants to fill up their own editorial system with the source data from all the various suppliers. That would quickly become unmanageable.
Current developments
No, it is not the source formats that we should exchange. It would be enough just to have a consistent format that we could use to exchange user information. Such an exchange format would be independent from the various individual specialities that make our editorial processes so efficient. It would be designed solely for the purpose of transitioning contents and their metadata and making them accessible to users, e.g. via a content delivery portal.
A tekom working group is currently working on developing such a standard. The iiRDS has the potential to evolve into that standard. But even if this development of a standard is not accepted in practise, there is still an opportunity to exchange information. That is because it is possible for manufacturers to define an exchange standard and require their suppliers to use it. In technological terms, exporting an exchange format from an existing XML source is not too much effort.
So we're excited that we can achieve our goal of providing users with all the information they need in an optimal form, either with or without a unified XML standard.
