Perhaps your organization and its data exchange partners are considering adopting an industry-standard XML vocabulary but are concerned that it may be too rigid or limited for your particular
purposes. Would it be difficult to get additions or extensions agreed and implemented by its bureaucracy? How long might that take?
In fact, these concerns may be unfounded because your community of interest can create extension subtypes in your own namespace and then use all the data structures and relationships in the
standard vocabulary plus the added flexibility of your extensions. This can usually be done with the blessing and cooperation of the standard authority because although options exist to prevent an
XML schema from being extended, they are rarely used. Everyone knows there is no point in trying to straitjacket the user community. The watchword is “Extend or die!”
For instance, what if the Bohemian Art Colony Association wanted to use the TDAN School schema (that we built in Part 1) to
exchange contact information among its members but they needed an Artist element that was a very creative extension of Lecturer and they felt that an Art Colony was significantly different from a
College or University:
Now they could talk about Colleges that had Artists on staff and Art Colonies that had both Artists and visiting Lecturers.
Meanwhile, the TDAN schema designer and the rest of the user community could be blissfully unaware of these new developments, because the technique required is the same substitution group subtyping
we reviewed in Part 1 (3rd Degree: Substitution Groups). You may have noticed that the schema syntax used to establish a
substitution group is all associated with the subtype elements – not the supertype. Declaring our supertypes as abstract was purely optional. Therefore, a substitution group can be created
using a head element from another author’s schema in another namespace, without so much as a by your leave. Well, provided that head element is globally declared but since we are living in
the Garden of Eden, that is a given.
To set this up, the Bohemian Art Colony Association first has to create a schema for their BACA namespace, declare the TDAN namespace and import the TDAN schema:
Now they can declare their Art Colony element and specify the TDAN School as its head element:
Similarly, they declare their Artist element and specify the TDAN Lecturer as its head element:
The complex type for Artist is defined in the BACA namespace because it extends the TDAN Lecturer type by the addition of a Creative Medium element:
Now the BACA schema is complete and it can be used to validate XML instances like this one that for brevity just documents an Art Colony with one Artist:
Note that the TDAN elements do not carry a namespace prefix, while the BACA elements do. That is because the instance document made TDAN the default namespace by not supplying a prefix:
It could have done the reverse or it could have provided prefixes for both namespaces, in which case all the elements would have to be prefixed.
Just a word of caution. Substitution groups spanning namespaces is not something the average Web developer encounters everyday. While it is well supported by validators and the major class
generators, once again Web services push-button WSDL/SOAP generators can be less sophisticated. So put your development toolset and run-time environment through its paces before committing to this
design pattern, and check with your data exchange partners too.
