Proposal: a building block approach to XML design

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

Hi Folks,

Remember Legos? It consisted of a bunch of building blocks that could be assembled in any number of ways. There was virtually an infinite number of things could be created.

Let's create XML Schemas in an analogous fashion; that is, let's create a set of small components that can be assembled in any number of ways. Let's specify the rules for assembling the components.

EXAMPLE

Suppose my inventory consists of books, bicycles, and watches. 

So I create an XML Schema for books, another for bicycles, and another for watches.

I deploy a web service that allows users to obtain book XML documents, bicycle XML documents, and watch XML documents.

However, I am not following the Lego pattern. I merely have a collection of pre-assembled components.

That's limited and limiting. No power. No diversity. No ability to generate dazzling complexity. Boring.

Conversely, if I had a set of building blocks (and assembly rules) then I could do this: 

    Assemble a handle bar with a watch.

That can't be done with my current schemas. Why? One reason is that there are no assembly rules. Need assembly rules. Legos has assembly rules: you can stack one Lego block on top of another but you can't assemble them side-by-side.

Add another building block:

    Assemble a handle bar with a watch and add a book component.

That assembly is getting interesting. Perhaps now I can create XML documents of bicycles that have a watch and can hold a book. Ha! Such a bike design would be perfect for a health club.

What's required of this Lego approach to XML design? 

(1) Need to identify an appropriate set of building blocks. 

(2) Need to specify the rules for assembling the building blocks.

Let's create complexity-generating XML Schemas (and RELAX NG schemas); let's create simple rules that enables dazzling innovation.

Thoughts?

/Roger