Structural Patterns in XML
Pattern recognition is fundamental to the human intellect. In pursuits as varied as art appreciation, home repair, and software engineering, patterns naturally inform our thinking and help us to mature. The practice of pattern recognition and use was first formalized with respect to object-oriented analysis and design (see GoF) and is for many people closely associated with OOP languages such as C++ and Java. As we will see, W3C XML Schema design can benefit from patterns, too.
Recognizing and Expressing XML Patterns
Since XML has no native behavioral aspect, the most useful patterns will naturally be structural in nature. We'll consider three such patterns in this article, and it should quickly become apparent that there are many more patterns ghosting about in our various XML systems, as yet latent and unnamed. Specifically, we'll consider:
Skeptics of pattern-friendly design often see patterns as overwrought cookie cutters: they ask why one's creativity as applied to the unique problems at hand should be replaced by the careless application of a one-size-fits-all template. Though these concerns don't form an indictment of pattern-based practices, they are valid and are, perhaps, best taken as a statement of how not to apply patterns. When used well, which often means not overused, patterns should help to crystallize one's thinking about a design problem and should save time in reaching a detailed and robust solution.
|
Related Reading 
XML Schema |
Flexibility of application is especially important. The patterns below are not for cookie-cutting, by any means, and none of the diagrams or examples should be extrapolated to a concrete solution without considering what's unique about the concrete problem. It's better to adapt patterns to specific uses than it is to blindly apply them.
Composite
Motivation
XML is naturally compositional: a whole A is understood to have a part or parts B. Most element types occupy a predestined position in a document's hierarchy. They always act as children of some other type and parents of some third or fourth.
In some models, a type is seen to act as its own parent. A tree of instances of this type then has no prescribed depth: it might have one, two, or a hundred levels. Further analysis often reveals basic differences between the instances with and without children. Yet the two are closely related; how should these be modeled as WXS types, and how can derivation be best applied?
Common examples include files and folders, users and groups, and windowing systems in which certain, sometimes all types of widget are known to include and to control child widgets.
Composite is a well-known OOP pattern, most of whose interesting aspects are behavioral. It's worth challenging the value of this pattern for a purely stateful system such as an XML document. In the solution described below even the basic task of accurately encapsulating state elements justifies the minimal weight of the pattern.
Solution
A primary solution pattern and two variations exist. In all solutions, a Composite type is recognized that has the responsibility of collecting children, and a Leaf type encapsulates some state unique to childless nodes in the instance tree. (We'll ignore the degenerate case in which it is not even worth separating Composite and Leaf types.) The major differences have to do with the direction of specialization: who should extend or restrict whom?
The primary pattern is the full expression and includes a Base type to capture common state. Here the roles of the three types are completely segregated:
(The UML notation in use here is spelled out in the previous XML Schema Clinic article. See "UML for XML Schema Design)".
Variations are best applied when there is no concrete motivation for the Base type. The remaining choice is almost one of taste: should Composite specialize Leaf by adding a child collection, or should Leaf specialize Composite with a constraint that it have no children? The latter approach is a bit more work in WXS, as the specialization combines extension and restriction:
Example
In this toy astronomy schema, the Composite pattern is expressed in three types, since both celestial bodies and orbital systems have position and velocity, but only bodies have mass and only systems have children. (Note that if systems could only have bodies as children, this would not be the Composite pattern at all.)
Pages: 1, 2 |
