Schema Modularity and Reuse
One of the benefits gained by using UML as part of our XML development process is that it enables a thoughtful approach to modular, maintainable, reusable application components. In the first two parts of this series, the PurchaseOrder and Address elements were specified in two separate diagrams, implying reusable sub-models. UML includes package and namespace structures for making these modules explicit and also specifying dependencies between them.
Figure 4 illustrates a UML package diagram of this purchase order model. A package, shown as a file folder in a diagram, defines a separate namespace for all model elements within it, including additional sub-packages. These UML packages are a very natural counterpart to XML namespaces. A dashed-line arrow between two packages indicates that one is dependent on the other.
When used in a schema definition, each package produces a separate schema file. The implementation of dependencies varies among alternative schema languages. For DTDs they might become external entity references. For the W3C XML Schema, these package dependencies create either <include> or <import> elements, based on whether the target namespaces of related packages are equal. A dependency is shown from the PO package to the XSD_Datatypes package, but an import element is not created because this datatype library is inherently available as part of the XML Schema language.
Figure 4 UML package diagram showing schema integration.
This object-oriented approach to XML schema design facilitates modular reuse, just as one would do when using languages such as Java or C++. A new vocabulary module could import our current Address package and define a new subclass of Address, or even further specialize USAddress with a new subclass. For example, BusinessUSAddress might be created with a new mailstop attribute. When transformed to XML Schema, this new subtype would automatically become available as valid content for the shipTo or billTo elements in a purchaseOrder. This is conceptually similar to the way one would create a new Java subclass within a new application-specific package, and other libraries are reused by importing, and possibly extending, their classes.