Over the past few years the OMG has created an architecture for managing metadata. This has resulted in the issuance of several official metadata standards. The core standard is the Meta Object Facility (MOF), and XML Metadata Interchange (XMI) is an extension of the MOF into the XML space. Thus, before focusing on XMI, it's important to grasp the basic concepts of the MOF.

The MOF proceeds from the fundamental proposition that the best way to describe metadata is to rigorously model its structure using object-oriented technology. The OMG's Unified Modeling Language (UML) is the industry-standard medium for OO modeling. Modelers typically use it to model business, GUI and infrastructure objects. The MOF standard selects a subset of UML that's appropriate for modeling metadata. This subset is called the MOF Core.

Consider a relational database system (RDB). The metadata in an RDB consists of definitions of tables, columns and more. Data models are sets of specific tables and columns. A typical (oversimplified!) data model might define both a Customer and an Account table. The former would have columns such as customer number, name, address and telephone number; the latter would have columns such as number, name and balance. This particular data model isn't the same thing as Customer and Account data. Instead, it describes the structure of the data. Therefore, the table and column definitions that make up the data model are called metadata - data about data.

A formal model of metadata is called a metamodel. In the previous issue of XML-Journal (Vol. 1, issue 3) the Objects & XML column contained a simple RDB metamodel that we'll use as our example. The MOF Core contains most of the UML constructs for expressing class models - classes, associations and subtyping. Therefore, UML modeling tools can be used to describe metamodels. Figure 1 uses UML notation to describe the simple RDB metamodel.

If you're a UML aficionado you're probably curious to know which UML constructs used for class modeling aren't included in the MOF Core. They are:

• AssociationClasses (associations that are first-class objects)
• Qualifiers
• N-ary associations (associations among more than two classes)

The reason for not including all the UML class modeling constructs in the MOF Core is that the MOF architects wanted to keep the MOF simple and its footprint small. Metamodels tend to be less complex than models of business, GUI and infrastructure objects, so the fancier UML concepts were omitted.

The MOF also defines a set of rules for mapping the elements of the MOF Core to CORBA IDL. This means that given a metamodel, IDL can be generated that specifies the interfaces for CORBA objects that represent models in a repository. The last XML-J issue showed the IDL for the RDB metamodel that was generated according to these rules. Say I want to store a data model consisting of a Customer and an Account table. These tables would be represented in a CORBA repository by CORBA objects that expose the Table interface generated from the metamodel by the MOF-IDL mapping. The name, address and other Columns would be represented in a CORBA repository by CORBA objects that expose the Column interface generated from the metamodel.

Thus it isn't necessary for a human to hand-code IDL for an MOF-compliant metamodel. The IDL is determined by the metamodel.

The key point is that the MOF Core is independent of CORBA, Java, XML or any other middleware or conveyance technology. Achieving this independence was quite easy since UML, of which the MOF Core is a subset, is technology-neutral. The approach of mapping each of the MOF Core's constructs - classes, associations and so on - to IDL technology can be applied to produce mappings to other technologies so that artifacts in line with these technologies can be generated as well.

Enter XMI
The MOF was defined before XML became popular. (We tend to forget how recent a phenomenon XML is.) However, the technology-neutral nature of the MOF Core made it relatively easy to produce a mapping from the MOF Core's elements to XML so that, given a metamodel, a Document Type Definition (DTD) could be generated. This DTD can be used to stream models that conform to the metamodel. For example, the DTD generated for our simple RDB metamodel would be used to exchange specific RDB data models.

The generated DTD defines XML elements for each element of the metamodel. For example, the DTD generated for our RDB metamodel defines an element corresponding to Table. That element describes how to convey a representation of a Table definition in an XML stream.

XMI is the OMG standard that defines the rules for generating an XML DTD from a metamodel. The current official version of XMI is 1.1.

Under the Hood
As described above, the key elements of the MOF Core are classes and associations. We use these elements to describe our simple RDB metamodel. In UML notation each element of the RDB metamodel is an instance of one of the MOF Core's elements (see Figure 2). Thus Table and Column are instances of MOF::Class, while the association between Table and Column is an instance of MOF::Association.

Figure 3 is a more informal overview of how XMI's MOF-XML mapping is applied to our RDB metamodel. The MOF-XML mapping defines how instances of MOF::Class and MOF::Association are mapped to DTD elements. Of course, the mapping for instances of MOF::Class are different from (but related to) the mappings for instances of MOF::Association.

Listing 1 is the main part of the XMI DTD generated for our simple RDB metamodel. This DTD was generated by IBM's alphaWorks XMI Toolkit, available on the alphaWorks Web site ( www.alphaworks.ibm.com). I've omitted a rather lengthy boilerplate header that makes up the first part of all XMI DTDs and isn't very interesting. Note that the navigable end of the association between Table and Column (the end with the arrowhead in Figure 1) is considered a property of the Table element. The metamodel names the navigable association end column, and that name is used in the DTD.

Rendering OO Models to Non-OO DTDs
The MOF Core, as a subset of UML, is object oriented; XML is not. In particular, XML doesn't allow subtyping (inheritance). Good object models make liberal use of subtyping. The architects of XMI wished to avoid having DTD elements repeat all the properties of all their ancestors since that would make it quite cumbersome to render typical object models to DTDs.

Figure 4 alters our simple RDB metamodel to use subtyping. The name attribute is abstracted out into a supertype named ModelElement. (According to UML notation, the name of this class is italicized in the diagram to denote that it is abstract. An abstract class can't have instances that aren't instances of one of its subtypes.)

Listing 2 demonstrates how an optional XMI feature avoids repeating a supertype ELEMENT's properties in ELEMENTs representing subtypes. This DTD was generated by a beta version of Unisys's pure Java metadata repository product called Complex Information Manager. For each class in the metamodel an ENTITY declaration that encompasses all the attri-butes of the supertype is generated. Subtypes need to reference only the ENTITY to essentially include all the inherited attributes. In this simple example the ENTITY declaration includes only one attribute because, in the metamodel, ModelElement has only one. Note: If a class is a subtype of another class (which is typical in a full-scale metamodel), then its ENTITY declaration also encompasses the ENTITY declaration of its supertype.

Since XMI specifies alternate rule sets for generating DTDs, they can be generated with or without these extra ENTITY declarations. The rule set used to generate a DTD doesn't have any impact on what streams can validate against it. The DTD in Listing 1 was generated with a different rule set, so it doesn't have the extra ENTITY declarations.

For various technical reasons separate ENTITY declarations are generated to encompass attributes and associations, respectively. Therefore, a DTD generated from an industrial-strength metamodel using the ENTITY-producing rule set usually contains a substantial sprinkling of ENTITY declarations. When XML-oriented people look at XMI DTDs, the ENTITY declarations tend to be disconcerting. While these DTDs are perfectly legal XML, they look unnatural to the trained XML eye. However, it's important to understand that the XML documents that validate against such DTDs don't look unnatural. The ENTITY declarations are shorthand for the DTD that makes the DTD more compact, if a bit strange looking. There's no way to avoid copying all the subtypes' properties in the XML document itself, so nothing looks out of the ordinary in an XMI-compliant XML document.

Some Industry-Standard XMI DTDs
Several specific XMI DTDs have been standardized by the OMG. Each was produced by feeding an MOF-compliant metamodel into an XMI DTD generator.

UML
The UML DTD is the most widely used XMI DTD. Many people think of UML only as a notation, but the official specification has a complete MOF-compliant metamodel. It's MOF-compliant because its elements are defined via the constructs of the MOF Core. This metamodel was fed into an XMI DTD generator to produce the UML DTD used by tools to export and import UML models.

Figure 5 shows the central part of the UML metamodel. It's actually more extensive than this class diagram suggests, but most of the elements not shown here derive in some way from these central elements.

Listing 3 is a fragment of the UML XMI DTD corresponding to the Classifier element of the UML metamodel. Note the property slot for isAbstract in the Classifier ELEMENT, which is fully qualified based on the name of the ancestor (GeneralizableElement) in which it was defined in the metamodel. This DTD was generated via a rule set that eschews the ENTITY declarations; that's why the isAbstract slot is copied down to the subtype hierarchy and appears directly in the Classifier ELEMENT.

CORBA Components
The CORBA Component Model (CCM) includes two MOF-compliant metamodels. One is a metamodel of CORBA IDL that includes some new IDL constructs defined by the CCM specification. It generates an XMI DTD that's used to exchange CORBA object models that could also be expressed in CORBA IDL.

The other CCM metamodel is for the packaging and deployment descriptors. A CCM component is deployed with a set of these descriptors expressed in XML. The XMI DTD generated from the packaging and deployment metamodel defines the structure of XML documents that contain these descriptors. Figure 6 shows a small portion of the descriptor metamodel.

The ComponentKind is the element in the component descriptor metamodel that supports designating a component as an entity, process, session or service. Figure 6 shows the declaration of ComponentKind as an enumeration and the Component element with an attribute of type ComponentKind. Listing 4 shows fragments of the XML DTD generated from the descriptor metamodel. These fragments correspond to the metamodel's ComponentKind element and tell us precisely how to encode a component to be an entity, process, session or service.

Common Warehouse
The OMG has adopted the Common Warehouse Metamodel as a standard metamodel for relational, record-oriented and hierarchical databases and for other aspects of data warehousing. Unisys, IBM, Oracle, Hyperion, Genesis and other companies responsible for CWM followed the MOF architecture so that XMI DTDs used for exchanging warehouse models could be generated from the metamodel.

Space doesn't permit showing the CWM metamodel, but suffice it to say that it's comprehensive. Listing 5 is a fragment of the XMI DTD generated from the metamodel for relational databases.

What Does "XMI Compliant" Mean?
When a vendor claims XMI compliance, you must dig a bit to find out exactly what this means. One level of compliance is support for some particular XMI DTD. An example is Rational Rose, which supports the UML XMI DTD. In addition, as the CWM is incorporated into products, support for any of the CWM XMI DTDs would be another example of this kind of compliance.

On the other hand, a product might support generating a DTD from a metamodel - a different kind of compliance. Furthermore, one vendor might support the rule set that generates the extra ENTITY declarations, another might not. Yet another might give you the choice of using either rule set.

Using XMI with Instance Data
Although XMI was originally designed for metadata exchange, we can also use it to exchange instance data. Consider the UML model in Figure 7. This isn't a metamodel. It's a model expressed via the UML metamodel. Instances of these classes constitute real user objects, not models. The model is platform-independent; that is, it's not specific to CORBA, EJB, XML or any other platform or conveyance technology.

Since the MOF Core is very close to UML, we can apply the XMI algorithms to a UML model, such as our bank model, to generate a DTD that tells us how to encode instances of the banking entities in an XMI stream. If we submit our UML bank model to an XMI DTD generator, we get a DTD that tells us how to encode the state of our instances, such as the state of specific Accounts and Customers. Thus the DTD for exchanging instance data can be derived from the formal UML model. Listing 6 is a fragment of the DTD.

Conclusion
The specification of a platform-independent model (or metamodel) as the source for generating a DTD is part of an overall architectural approach that also uses a platform-independent model as the source for the production of artifacts for other technology environments. The other environments include CORBA, EJB and LDAP. This approach has been dubbed model-centric architecture. The model distills the essential information semantics from platform concerns so they can be readily reused in different platform environments. Furthermore, model-centric architecture allows many platform-specific artifacts, including XML DTDs, to be automatically generated by generic tools. This increases the degree of automation that can be applied to the production of DTDs and other artifacts, thus enhancing the scalability of these technologies.

References

• alphaWorks XMI Toolkit: http://www.alphaworks.ibm.com/tech/xmitoolkit
• Common Warehouse Metamodel (CWM) Specification, February 11, 2000: http://cgi.omg.org/cgi-bin/doc?ad/00-01-01
  http://cgi.omg.org/cgi-bin/doc?ad/00-01-02
• Meta Object Facility (MOF) Specification, Version 1.3, September 27, 1999: http://cgi.omg.org/cgi-bin/doc?ad/99-09-05
• Unified Modeling Language (UML) Specification, Version 1.3, June, 1999: http://cgi.omg.org/cgi-bin/doc?ad/99-06-08
• Unisys Universal Repository: http://www.urep.com/marketplace/urep
• XML Metadata Interchange (XMI) Specification, Version 1.1, October 25, 1999: http://cgi.omg.org/cgi-bin/doc?ad/9910-02
  http://cgi.omg.org/cgi-bin/doc?ad/99-10-03