Luckily, translating the definition of the different components into XML is a relatively straightforward operation. In fact, the component design has been made directly in XML. XML was part of the very early design decisions, and therefore has much influenced the design. The reasons for choosing XML as the most fundamental data format are several:
"XML shall be straightforwardly useful over the Internet" ([xmlspec]). Actually, XML fits perfectly into the scheme of using URIs and the existing URL protocols, being related to HTML as it is.
XML also is immediately useful as a data storage format, immediately distributable using any web server. This is not a small point, as getting involved in the business of using a database could be unnecessary overhead for small content providers and for our prototyping.
"It shall be easy to write programs which process XML documents" ([xmlspec]). And there are indeed a multitude of parsers for XML for any important programming language.
"XML documents should be human-legible and reasonably clear" ([xmlspec]). This has much helped us in prototyping, as no special tools are needed to analyze an XML document.
"XML documents shall be easy to create" ([xmlspec]). This point is incredibly important. You can create XML documents using nothing but a text editor, which was, by necessity, the case before we had constructed a complete editor. But it is also easy to create XML documents from inside a program, which has helped us in the prototyping.
This list could easily be continued. Of course, there are problems, such as the following:
The updating procedure when you are not located on the same file system as the XML files turns out to be complicated, suffering from the same difficulties as updating HTML pages. But this is an expected side-effect of the extremely simple distribution. The components in XML format are not primarily meant to be edited from a distance, but rather to distribute ready-made components.
XML is not the most compact format imaginable. However, we do not expect the components to constitute the largest part of the data used, but rather the content in the form of images, videos, etc. Also, this non-terseness in representation is the basis of many of the advantages of the XML binding, so it will be conditionlessly accepted. And it is still relatively lightweight, in comparison with, for example, CORBA.
The canonical programmatic interface to XML, the Document Object Model (DOM), is a very heavyweight representation not suitable in all situations. We have solved this problem in the class library. See Chapter 12, The Class Library.
The XML Metadata Interchange (XMI) format is designed as a serialization of a UML metamodel described using the MOF. This serialization is done using XML. Why isn't this a suitable XML binding of our objects? The reason is that it shares many of the problems with the MOF as described in the section called Design Discussion in Chapter 1, Database structure, more precisely:
Object oriented analysis and design fixation in the modelling.
Distributability problems. An XMI document describes all classes and associations contained in one closed model, typically one whole Repository. This is orthogonal to the modular design we want, and indeed, the goal of XMI as described in [xmispec] is to ease
the problem of tool interoperability by providing a flexible and easily parsed information interchange format. In principle, a tool needs only to be able save and load the data it uses in XMI format in order to inter-operate with other XMI capable tools.
That is, XMI is not designed as a way to decentralize information but as a way to transfer complete models, a concept that in a sense does not exist in our system, as our models usually not are closed.
Prototypability. The XMI Specification is truly a large one, and would distract us from more important tasks.
So we have decided not to use XMI. This is also the right place to mention UML Exchange Format (UXF) described in [uxfspec] that is a more lightweight XML description of UML diagrams which has inspired us in many ways.