[This local archive copy is from the official and canonical URL, http://helios.hud.ac.uk/staff/scomaw/xmlstudy/xminotes.htm; please refer to the canonical source document if possible.]
XML study notes Copyright Ann M Wrightson 1999
This set of XML study notes was prepared to support class-based and independent study at the School of Computing and Mathematics at the University of Huddersfield. These notes are open access; registered students should ensure that they also make full use of the specific material for their modules (password access).
XMI (XML Metadata Interchange) has been created within the technology development process of the Object Management Group, with the aim of allowing developers of distributed systems to share object models and other structured data, created using OMG technology, over the Internet. Most of the information in these notes is drawn from the XMI proposal document (OMG Document ad/98-10-05), which is available from their website. Please refer to that document for further detail.
The main purpose of XMI is to support the exchange of metadata (eg structured data describing object based models for information systems) between modelling tools based on the OMG UML (an object based modelling language), and repositories based on the OMG MOF (a standard for describing metadata structures, such as data describing UML models, and repository interfaces). XMI is an integral part of the OMG architecture, which is aimed at supporting interoperation of information systems within diverse and distributed installations. Full details of this architecture are available on the OMG website.
XMI uses XML so that XMI data exchanges can take advantage of the extensive technology development surrounding XML and the Web, rather than creating an alternative competing standard for structured data exchange.
'XMI' is made up of:
XMI has been developed in response to an OMG requirement for a Stream-based Model Interchange Format, in the specific context of UML; however, XMI could also be used for other kinds of structured data interchange. XMI is likely to be useful where, although XML is capable of expressing the content and structure of the data to be exchanged, there is additional information (for example, constraints on data values, or constraints on data structure) which is beyond the expressive capability of XML, and which is essential for a full exchange of meaningful information. In particular, the XMI development team considered XMI in relation to product data exchange standards defined within ISO 10303 (STEP), and their discussion is summarised below.
This summary concentrates on XMI as an application of XML to the exchange of structured information.
XMI is designed to be used for exchanging information not only between repositories driven by OMG specifications, but also with and between repositories which are not driven by OMG specifications (because of XML's widespread acceptance, beyond the sphere of influence of OMG, as a standard for representing structured information in the context of the WWW). So, what kind of information is going to be exchanged using XMI?
In OMG's terms, XMI supports the exchange of any kind of structured data that can be described using MOF. And what the MOF principally does is support the specification of models. These models are precise structured descriptions of collections of meaningful information. MOF models are object-based; they can describe simple data structures, but they also support levels of abstraction, the description of relationships and attributes, and rules governing structure and consistency. Since there are many possible kinds of models in a typical system, the MOF supports the specification of classes of models with common structure and constraints, at different levels of abstraction. All these features are integrated within a uniform modelling framework.
This uniform modelling framework allows all levels of MOF-based information to be exchanged using XMI. Structured data can be exchanged alongside representations of models governing that data. This includes model descriptions, complete models, and model fragments. (XMI can also be used to interchange information as incremental differences from a base version.)
So what is the added benefit of XMI over plain XML? - XML itself provides for structured data, and syntactic specifications of the structure of that data; XMI provides a mechanism for encoding many levels of information modelling into the single syntactic interchange structure of XML.
The core of XMI is a pair of parallel mappings: between MOF metamodels (model descriptions) and XML DTDs; and between MOF metadata (model instances) and XML documents. Any repository or tool that can encode and decode XMI streams can exchange structured information with other repositories or tools with XMI capability. XMI capability does not necessarily mean that the repository or tool is driven by MOF: it could be based on a mapping between particular MOF models and an internal model; or on a standardized mapping between a class of MOF models and a (non-OMG) interchange standard supported by the repository or tool. (See notes on XMI and ISO 10303 (STEP) below, for more on this aspect of XMI; See notes on XMI design goals below, for more detail on the design of XMI.)
The XMI proposal describes XML as "a new format designed to bring structured information to the Web ... in effect a Web based language for electronic data Interchange." It explicitly positions XML between HTML: "the automatic extraction of information from HTML documents is difficult since HTML tags are designed to expressed presentation rather than semantic information", and SGML: " a sophisticated tag language which separates view from content and data from metadata...due to SGML's complexity, and the complexity of tools required, it has not achieved widespread uptake ... XML is a subset of SGML that maintains the important architectural aspects of contextual separation while removing nonessential features".
Although there are sound technical reasons for using XML, it is clear that much of the motivation for using XML in this context comes from the current and expected structure of the business environment related to XML. The proposal document's justification for using XML contains the following technical and business factors:
[There is an interesting balance here between XML being new and different from both HTML and SGML, and so providing new opportunities - and previous experience with HTML and SGML being seen as validating the use of XML.]
As noted above, any repository or tool that can encode and decode XMI streams can exchange structured information with other repositories or tools with XMI capability. This capability could be based on a mapping between particular MOF models and an internal model, or on a standardized mapping between a class of MOF models and a (non-OMG) interchange standard supported by the repository or tool.
In this context, the ISO STEP standard for product data exchange is particularly interesting. It has an established user community; its aims for information exchange are very similar to MOF/XMI; and STEP's domain of application overlaps with that of OMG technology. In addition, an international working group - independent of OMG - is currently developing ways of exchanging STEP-driven data using XML; and OMG has a "Manufacturing Domain Task Force" which is well aware of STEP. It will be interesting to see how this situation develops over the next couple of years.
This section summarises the material related to STEP in chapter 3 (3.2,3.3) of the XMI proposal document.
The XMI proposal does not address how to support semantic interoperability [i.e.exchange of data with enough context, &/or structural description, for the data to convey meaningful information] between tools that share and manipulate STEP schemas and STEP schema instances. However, assuming that MOF metamodels for STEP schemas are defined, previous experience with MOF and its precursors, in domains which entail model and schemas transformations, suggests that XMI could be used to interchange STEP schemas and instances.
The submitters believe that MOF is rich enough to be used to define STEP schemas at the same level as the UML metamodel. A possible approach is to define a mapping between the STEP metamodel and the MOF meta-metamodel so that STEP schemas can be treated as MOF metamodels. Alternately, a MOF metamodel for STEP that allows STEP schemas to be expressed as MOF based models. The MOF already provides facilities for expressing constraints and rules on metamodels; if we assume that STEP is incorporated into the MOF metadata framework using the second alternative above, then STEP conformance requirements can be handled as part of the MOF metamodel for STEP.
The focus of the XMI proposal is on current and emerging OMG metadata standards. The submitters believe that integration of XMI and STEP EXPRESS to address EDI and related requirements is an important next step.
Note: The original request for proposals by OMG, to which the XMI proposal was a response, contained the following optional requirements, which were not directly addressed in the XMI proposal.
Proposals may identify specific modelling language differences between EXPRESS and the MOF/UML and discuss ways to map between these languages. A direct mapping of all the concepts in either language to the other may not be possible.
Proposals may identify the impact of the proposed SMIF specification [XMI] on existing schema definitions and transfer files produced using STEP EXPRESS. This may include identification of any changes to STEP EXPRESS files required to produce valid syntax and encoding per the proposed SMIF specification. Submissions may include a specification for converting STEP schemas and/or transfer files created using STEP EXPRESS standards to make them compliant with the proposed SMIF specification.
This section summarises the XMI design goals, described in section 4.4 of the XMI proposal. Some of this material assumes knowledge of the OMG architecture supporting development and deployment of distributed object based information systems; there is a concise review of this architecture (and an interesting review of XML, from the point of view of data exchange) in sections 4.2 and 4.3, respectively, of the proposal document.
The XMI proposal defines DTD generation and stream production rules that can be used to transfer any models described by a MOF metamodel.
For example:
The XMI specification is designed to allow the automated generation of XML DTDs based on the original MOF specification of a metamodel. Such DTDs are pretty much guaranteed to be a faithful reflection of the original metamodel. The XMI specification also contains rules for stream production based on the MOF metamodel. These rules can be used to automatically generate XML import and export tools for instances of a metamodel.
XML's a tree based element structure emphasises nesting [of element content] over linkage. The XMI proposal follows this lead by rendering instances of "contained" Attributes and References in an MOF metamodel as nested XML elements.
The XMI proposal does not map all MOF DataTypes onto distinct elements in the XMI DTD. It is arguable that XMI should map data types so that the XMI DTDs allow for validation. However, if XMI were to do this, there is a risk that XMI integration with future W3C proposals would be problematical. XMI therefore optionally encodes most CORBA data types using "boilerplate" DTDs. It is anticipated that this decision will be revisited in the future.
[There are strong parallels here with design issues in current work towards ways of exchanging STEP-driven data using XML.]
Unfortunately, an XML DTD can only express as subset of the structure and consistency rules contained in a MOF metamodel. The consumer of an XMI document may need knowledge of the metamodel that is not conveyed in the DTD. Similarly, an XMI document producer needs full knowledge of the metamodel to ensure production of correct document content. This knowledge can be obtained from the MOF metamodel, which can itself be exchanged as an XMI document.
If a MOF repository sends the XMI files for both a model and its metamodel, a preceding MOF repository has a sufficient information to fully reconstruct the model, even if it had no prior knowledge of the metamodel.
MOF metamodels developed using the UML graphical notation tend to be under-specified in ways that are significant for XMI DTD and document production. Rather than addressing these issues in XMI, it is assumed that any metamodel that is a source or target for XMI Interchange is fully specified.
XMI supports the interchange of model fragments as well as complete models.
XMI does not require a model to be fully validated as a precondition for metadata interchange; a minimum level of correctness is specified.
[4.4.7 and 4.4.8 together are intended to support the exchange of models under development, or portions of large models. To be successful, these interchanges will need specific coordination and agreements between producer and consumer.]
It is recommended that versioning issues are addressed in a future proposal.
[There are mature and well developed concepts for versioning and configuration management in STEP; it will be interesting to see whether the contacts between OMG and STEP participants lead to these being applied in OMG technology.]
XMI supports the exchange of non-standard extensions alongside standard metamodels. XMI places no requirements on an XMI document consumer to do anything sensible with metadata corresponding to extensions. However, to support round-trip exchange between heterogeneous tools, these sections should be preserved.
XMI can be used to exchange operational data as well as metadata (provided that MOF models are suitable for modelling the data).
The MOF and UML DTDs published in the XMI proposal document have been automatically generated from the current versions of the MOF model and the UML metamodel, and are therefore interim normative XMI DTDs for MOF version 1.1 and UML version 1.1 respectively. In the long-term, the responsibility for producing definitive metamodels and corresponding DTDs should rest with the groups who propose and maintain the specifications that need them.
Ann M Wrightson, April 1999