XML.com: UML For W3C XML Schema Design

UML For W3C XML Schema Design
by Will Provost | Pages: 1, 2

Modeling Relationships

Relationships between UML classes line up nicely opposite the WXS options. In UML, composition (aggregation by value) is not the most basic relationship type, but in XML it is, and so we start there. Composition maps to composition, and cardinality maps to occurrence constraints. The role name can be mapped to the desired attribute or element name; it can take advantage of the attribute stereotype and the @ prefix.

<xs:complexType name="Dealership">
  <xs:sequence>
    <xs:element name="inventoryItem" type="Part" 
      minOccurs="0" maxOccurs="unbounded" />
    <!-- Other content omitted. -->
  </xs:sequence>
</xs:complexType>

UML associations are trickier for XML, which is fundamentally hierarchical. XMI maps associations to XLinks, which is sound but exemplifies the problem with using XMI for WXS design, as XLinks are outside the Schema vocabulary. Within WXS associations map most naturally to key references. (This is the major issue with Carlson, who maps all associations as compositions, blurring the distinction between association by value and reference. Associations that are not explicitly modeled as compositions must be preserved in the schema, so that a single instance with multiple references in an object graph is not spuriously multiplied.)

UML associations

Problem: key and referencing fields must be identified.

Solution: key stereotype of UML attributes; ordered list of referencing fields encoded in the association role name.

Another difficulty crops up here. Core UML can describe the cardinality of the association, can give it a name from each side and express navigability. What it cannot do is identify the selector and field components to be used in the WXS.

This information is actually more relational than object-oriented in nature, and it exposes one of UML's chief weaknesses: identifying key fields. There is no real home for this information in the UML metamodel -- in UML identity is strictly implicit -- and yet these paths will need to be specified to complete a generated W3C XML Schema. This could be addressed as a tag or a stereotype, and although it's a bit of a forced fit, I propose a key stereotype of UML attributes, to be presented via a simple shorthand. Note that this may overlap with the attribute stereotype, resulting in notation such as Ťkeyť@unitID. UML modeling tools can automate a mapping between this stereotype and the definition of an xs:key governing the enclosing type.

Also, the association itself will need to identify the ordered list of referencing fields to generate an xs:keyref. This can be derived from the associating role name; multiple field names can be packed into this name as a list, or can be attached as tagged values.

<xs:element name="Dealership">
  <xs:complexType>
    <xs:sequence>
      <!-- Referenced types Car and Salesman not shown. -->
      <xs:element ref="Car" minOccurs="0" 
	       maxOccurs="unbounded" />
      <xs:element ref="Salesman" minOccurs="0" 
	       maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>
  <xs:key name="SalesmanKey">
    <xs:selector xpath="Salesman" />
    <xs:field xpath="@sellerID" />
  </xs:key>
  <xs:keyref name="CarToSalesman" refer="SalesmanKey">
    <xs:selector xpath="Car" />
    <xs:field xpath="@soldBy" />
  </xs:keyref>
</xs:element>

Mappings of UML association cardinality are in fact the primary subject of an earlier XML Schema Clinic article; see "Enforcing Association Cardinality" for a full discussion of implementation strategies.

UML specialization

Problem: two mechanisms for XML complex-type derivation.

Solution: Ťrestrictionť stereotype of UML specialization.

UML specialization maps more neatly to XML type extension for complex types. Both imply that the derived-type state elements are appended to the base type's state model.

The only trick here is that XML offers another means of complex-type derivation, i.e., estriction. This is another appropriate use of the UML stereotype, and so we define restriction as a stereotype of specialization. In this case the derived UML class will state the changes to the base-class content model; the Schema generator will be expected to merge these changes into the base content model for restatement in the restricted complex type.

Miscellaneous Schema Information

xs:schema attributes

Problem: various attributes on xs:schema with no natural home in UML.

Solution: tagged values for targetNamespace and element/attributeFormDefault.

One key question we've yet to address is where the schema element fits into the UML model. There are options here: either the entire model can be directed to a schema, or in more complex models packages may be used to model XML namespaces. In either case there must be a property that identifies the target namespace URI.

The elementFormDefault and atributeFormDefault attributes of the schema element truly live outside the UML world view. These must be properties at the same scope as the target namespace, whether package or model.

Also, we've thus far assumed that all content models are sequences. To model a choice, use an {xor} UML constraint; if you need to model xs:all, either an {unordered} constraint or a separate stereotype of the UML class would do, but the former is a better conceptual fit.

Directions: Behavioral XML?

For those of us who've found the absence of behavior modeling frustrating, it's a relief to realize that there is indeed more to XML than data structures. With a robust profile in hand by which WXS can be expressed as UML, we can turn to more adventurous uses, especially for XML messaging. As with all things XML, data is never far from metadata; the WSDL specification shows off XML's ability to encode method invocations, and it plays a schema-like role in prescribing XML message content.

From the humble beginnings of data-centric XML, WSDL descriptors rise once again to the level of object-oriented encapsulations. Now, suddenly, the full power of UML can be brought to bear. A WSDL portType stereotype can express the semantics for an entire Web service and can be the source for a complex generation of not only WSDL and WXS documents, but also service or client code to support SOAP or HTTP messaging. No specific mapping rules are proposed here, but hopefully the following hypothetical will whet the reader's appetite:

For taking the time to discuss various concepts in this article, I'd like to thank Richard K. Fisher and Jean Pierre LeJacq.

Modeling Relationships

Miscellaneous Schema Information

Directions: Behavioral XML?

Recommended Reading