Extension standards

One key design decision that was made during the development of XML was to keep the language small. This was done in order to encourage application developers to support the standard, and to help ensure that the cost of development would be minimized: a strategy that has worked extremely well, as the subsequent widespread availability of low-cost (sometimes free) XML tools has demonstrated.

Another key decision made was that XML should be backward compatible with SGML, so that existing SGML tools could be utilized in XML projects, and protecting the investment of organizations that had already adopted SGML.

These two decisions were certainly valid, but as a result there has been pressure to:

• replace some of the more archaic SGML-compatible features with simpler yet more powerful, alternatives

• improve upon or simplify some existing SGML-based adjunct standards

• enhance XML to better support data exchange applications

• generally extend XML in new and interesting ways.

It was understood that the only way to do these things, without complicating XML itself, was to introduce a number of adjunct standards. Individual applications could then choose whether or not to support a particular extension standard as appropriate to their purpose.

One by one, functional areas not tackled by the XML standard have been addressed by new, adjunct standards. Some of the old SGML-related standards have been dusted down and re-worked (often simplified in the process), and most of the more significant ones have been developed by the W3C (see www.w3.org).