RE: XMI

[Frederic Keymeulen <frederic.keymeulen@seagha.com>]

Please do not send any more mails.

txs

-----Original Message-----
From: Chris [mailto:chris@cnelson.demon.co.uk]
Sent: woensdag 24 mei 2000 16:17
To: ebxml-core@lists.oasis-open.org
Subject: XMI


I am intrigued by the debate on XMI as people seem to be misinformed on
the nature and role of XMI.  I am not an expert, but I do know that XMI
can carry data instances and is therefore quite capable of transporting
a purchase order, invoice etc.  The Common Warehouse Metamodel from the
OMG is proof of this as it uses XMI as the transport mechanism for data
warehouse metadata, such as the structure and semantic content of a
relational table.  The first use of XMI was for exchanging UML models
between UML modelling tools.  However, the CWM is the first of (probably
many) OMG standards that will use XMI for exchanging data.
XMI is not for the light hearted, not will the document or DTD be easy
to understand or to read. But that is not the intent of XMI.  The intent
is to be machine readable so that the class instances can be faithfully
re-created according to the UML model of the business domain.  The CWM
classes do have simple methods such as create and destroy.  There
are/will be XMI tools that will create/read XMI to/from Java classes.
Whether this is relevant to ebXML is another issue as it means that
inter-operability should really be defined at the level of the classes
(model), and not at the level of the XML.  However, given a good ebXML
architecture (another subject), then I don't think this need be a
problem, as it will be easy to create simpler XML documents if required
from the same classes (e.g. for processing or presentation via XSL).  I
cannot help but come to the conclusion that we will not end up with one
XML specification for a particular business function/industry
sector/etc./etc., but what we need is to build the architecture that
will let everyone play the game.  The only commonality will be the UML
model, and the data in the different "formats" (including, by the way,
EDIFACT and ANSI X.12, as well as specialised DTDs) need to be mapped to
classes implementing the model.  This is really a software issue, and is
isn't all that difficult to solve.  
Getting back to XMI, the XML in the XMI is really quite "flat" because a
UML model has no hierarchy.  If you want a hierarchical DTD, then don't
choose XMI, but if you want a DTD that can be used to transport
faithfully the object instances from the application, then XMI is the
tool.  If you want an architecture that can bind together all the
different needs and syntaxes, including XML, then base the architecture
on getting data into and out of the object classes, from and to whatever
form (i.e. many to many translation via a common set of classes, thus
reducing exponentially the number of transformations that have to be
done).  If this approach is adopted, then XMI is a valid (but not the
only) XML that can be used.  

Regards,
Chris Nelson
Dimension EDI