by Eric van der Vlist is published by O'Reilly & Associates (ISBN: 0596004214)
It is a pleasure to see this first book on RELAX NG, particularly as—at the time of writing—RELAX NG does not enjoy the same level of usage and corporate support as its main rival, W3C XML Schema. Clearly this book is not for those who like their technologies chosen for them by major vendors. But I believe that for those who prefer to select their technologies for themselves, RELAX NG has substantial utility.
Back in February 1998, when the XML 1.0 Recommendation was first introduced, XML was radical in its simplicity compared to SGML. The innovation in XML was not so much in what it added to SGML but rather in what it took away. However, XML is now part of a much larger family of standards from the W3C. Collectively, these are much more complex than SGML ever was. It is hard for a newcomer to understand what is the right way to use XML and what are the core ideas.
RELAX NG is based on a very clear vision of XML processing. XML is useful only because XML processing components can interoperate. Most XML processing components do not input and output arbitrary XML documents. To combine XML processing components reliably, it is therefore essential to be able to specify the inputs and outputs of XML processing components and to verify mechanically that components are behaving according to their specifications. The most important issue in doing this is choosing which abstraction of XML to use for specifying the inputs and outputs of XML processing components.
XML standardizes only a syntax, but if you constrain XML documents directly in terms of the sequences of characters that represent them, the syntactic noise is deafening. On the other hand, if you use an abstraction that incorporates concepts such as object orientation that have no basis in the syntax, then you are coupling your XML processing components more tightly than necessary. What then is the right abstraction? The W3C XML Infoset Recommendation provides a menu of abstractions, but the items on the menu are of wildly differing importance.
I would argue that the right abstraction is a very simple one. The abstraction is a labelled tree of elements. Each element has an ordered list of children in which each child is a Unicode string or an element. An element is labelled with a two-part name consisting of a URI and local part. Each element also has an unordered collection of attributes in which each attribute has a two-part name, distinct from the name of the other attributes in the collection, and a value, which is a Unicode string. That is the complete abstraction. The core ideas of XML are this abstraction, the syntax of XML, and how the abstraction and syntax correspond. If you understand this, then you understand XML.
In my view, the most important lesson to learn from SGML is not the syntax but the concept of generic markup. Generic markup means describing things in terms of their semantics rather than their appearance. Generalizing, the lesson is to keep your data as independent as possible of assumptions about how you are going to process it. The way to do this for XML is to focus on this minimal labelled-tree abstraction. The more you build alternative abstractions on top of that and look at XML instead as a serialization of some other abstraction such as an object or a remote procedure call, the more you build in assumptions about how components will process XML and the less rationale there is for using XML.
RELAX NG is based firmly on the labelled-tree abstraction. All a RELAX NG schema does is provide a way to specify a class of XML documents in terms of this abstraction. Other schema languages, including W3C XML Schema, also provide this capability. Where RELAX NG differs from most other schema languages is in what it leaves out. It leaves out alternative abstractions of XML (such as W3C XML Schema's PSVI) that compete with the fundamental labelled-tree abstraction. It leaves out anything for transforming the document no matter how simple (such as default attributes). It leaves out anything used for parsing the document (such as entity declarations). It leaves out anything for mapping between XML and programming language data structures or relational databases. Just like XML itself, much of the advantage of RELAX NG stems from what it leaves out.
RELAX NG's vision of XML processing is not one that puts RELAX NG at the center of XML processing to the exclusion of other technologies. Rather the RELAX NG vision is one in which XML, or more precisely, the syntax and minimal labelled-tree abstraction implicit in that syntax, is at the center of XML processing. The only thing you are locked into with RELAX NG is XML. This is why a lack of vendor support need not prevent you from using RELAX NG. I hope RELAX NG will not only prove to be useful in itself but also will be an example to the XML community of the benefits of focusing on XML as XML.
This text is released under the Free Software Foundation GFDL.