- UML Profile for XML Schema
- Customizing the PO Schema Design Model
- Creating XML Schemas with hyperModel
- Schema Modularity and Reuse
- Tips for Success
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
){kind=link}
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.