Small XML languages versus large XML languages - which is better?

["Costello, Roger L." <costello@mitre.org>]

Hi Folks,

Issue:

	Is it better to create small, simple, tightly-focused 
	XML languages or large, comprehensive, data-rich 
	XML languages?

Below I discuss this issue. I present the advantages and disadvantages of each. I then arrive at a conclusion. I welcome your comments.

-------------------------------------
RSS is a small XML language. RSS has been well received by the web community and is broadly adopted.

Perhaps, based on the success of RSS, we can conclude that smaller is better?

But hold on. Consider this: XML documents are usually not going to be printed out. Consumers typically aren't going to shuffle through a stack of papers to get the information they want. Rather, the XML goes into a computer and the consumer interacts with the data via some software. Since the XML contains lots of information, the software can create a rich user experience. In light of this, perhaps it is better to have lots of data; in fact, the more data, the better. So a simple, lightweight XML language is just the opposite of what is desired. Instead, a heavy, data-rich XML language is desired, coupled with good software.

But wait! Since we are assuming that consumers interact with the data via software, it is certainly reasonable to assume that the software is capable of pulling together many small documents and thereby provide the same data-rich experience as with a single large XML language. Furthermore, the software can pull in as many or as few documents as needed; it's not one-size-fits-all as it is with a single XML document.

Advantages of a large XML language (coupled with good software):

1. All the data that consumers might need is at their fingertips.
2. The software (being used by the consumer) can do cross-correlations and all kinds of analysis on the data; there is a lot of value-add and the consumer has a rich user experience.

Disadvantages of a large XML language:

1. The classification level of the document may become elevated as a result of combining the data (separately the data may be unclassified, but when combined it becomes classified). This may result in prohibiting the data from being shared.
2. Large, complex languages are, well, large and complex. At the consuming end, the software may shield the consumer from the largeness and complexity of the language. But at the authoring end there is no way to avoid the largeness and complexity. The language is hard to understand and develop to. The chances of developer errors grow exponentially with the size of the language.

Advantages of a small XML language:

1. Less chance of the classification level becoming elevated. Thus, there is greater likelihood that the data can be shared.
2. Small, simple languages are, well, small and simple. At the authoring end, developers delight in the ease with which they are able to create and understand the documents and software. The chances of developer errors are minimal.
3. A customized user experience is possible: at the consumer end the software can pull together as many or as few documents as needed.
4. My retirement advisor always tells me, "Have a diverse portfolio, don't put all money in one fund." With small vocabularies that sage advice is adhered to since the data is diversified across multiple small documents.
5. The software (being used by the consumer) can do cross-correlations and all kinds of analysis on the data; there is a lot of value-add and the consumer has a rich user experience.

Disadvantages of a small XML language:

1. There is an increased configuration management problem since the complete set of data is to be scattered across multiple documents.

CONCLUSION
As I reflect on the advantages and disadvantages, it becomes singularly clear to me that it is better to create multiple small XML languages than one large XML language.

Thoughts? Am I missing anything in my list of advantages and disadvantages?

/Roger