For Compatibility

The somewhat strained tone in this definition evidences the somewhat strained quality of debate that created it. The problem is simple. Being compatible with SGML is a real virtue, for several reasons:

• It allows the use of the rich inventory of existing SGML tools on XML documents.
• It protects document owners from vendor rape; a demand for standards-compliance is one of the few defenses an information producer has against the natural desires of the software vendor to lock his data into the vendor's products.
• It helps sell products to government agencies and the like who like to buy standards-conformant stuff.

On the other hand, SGML was designed in the early-to-mid 1980s, and with experience, we have come to be keenly aware of some design errors. It was very tempting merely to eliminate them from XML, and some of us thought that this was the way to go. Eventually, we decided to include some rather questionable constraints on XML simply for the sake of compatibility.

One of the reasons why this was easy was the eagerness of the SGML community to work with us, and in fact to modify SGML to remove some of these irritants, to an extent that was very gratifying.

Back-link to spec