OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: ebXML Representtion of Metadata

Sridhar made the presentation on XMI via teleconference at the Orlando
meeting.  The reg-rep PT is still looking at XMI as a way to store UML
models in XML syntax, and this represented as the Transformation Service
package in the reg-rep UML domain model.  Also, we hope to generate the
interfaces for an ebXML Registry and Repository based on our UML model using
XMI and XSL.  This is not a guarantee however, and we will revert to
hand-developed mode if time is pressing.  This will be in Part 4 of our

We have looked at the production rules for DTD on model instances, and
believe that is NOT the way forward, but rather we are looking at different
set of production rules SIMILIAR to those in the XMI 1.1 specification.  The
first target in the XMI document is to query for the classes stereotyped as
<<Interface>, resulting in a collection of operations per interface class.
Each operation's signature needs to be modeled as a class diagram for the
request and the response as I showed in Brussels at the opening plenary.
This will get us SOAP-like messages for operation invocation.  The
transformation is being tested using XSL.  A given UML model may give us
100+ different DTDs or Schema, depending on the model.  

The biggest problems we saw with the XMI spec is 1) the mandatory
<XMI>..</XMI> tags which I am currently ignoring in the test XSL, as well as
2) ordering which I believe is a general problem with the model instance
philosophy anyhow.  

Regarding #1, I question whether the <XMI> tags are an OMG goal to promote
the "XMI origin" of the generated DTD. If that is the case, I suggest that
all XML documents in the world have the root tag of <Computer> since XML
originates on a computer.   The concept does not fly in my book.  I hope
that OMG will relax that requirement in the specification.  

Regarding #2, people interpret models differently based on their
"viewpoint", therefore order is in the eye of the beholder.  Targeting
<<Interface>> classes is easy and precise, since the order is based on
walking through collections.  Its not rocket science.

We hope to have these production rules into the TMWG UML Profile and
Methodology at the July meeting.  

Finally, I too am not a big SOAP fan (as it is currently written) since it
is too tight a binding to the operation itself, and promotes the concept of
"bridges" - which software vendors seem to like in order to sustain their
business.  Lose all the arrays, and other argument "types", and treat the
XML document as a string for each operation argument, and then the spec is
philosophically "right-on".  Leave the operation implementation up to
others; i.e., let me determine whether I parse it with the DOM, SAX, or
custom, and call my RPC, ActiveX, or CORBA interfaces.  Operation invocation
should be the only goal with the specification, and it should be a simple
specification at that.



-----Original Message-----
From: Iyengar, Sridhar [mailto:Sridhar.Iyengar2@unisys.com]
Sent: Tuesday, May 23, 2000 8:10 PM
To: David RR Webber; Cory Casanave
Cc: ebXML-Architecture List; ebxml-core@lists.oasis-open.org; Miller,
Robert (GXS); Iyengar, Sridhar
Subject: RE: ebXML Representtion of Metadata

<SNIP>  Sridhar did a presentation on XMI in Brussels.  I hope I'm not 
miss quoting - but XMI is still a technology in development.

My sense is that it will take a year or there abouts to get all the kinks
worked out.  Also XMI is serving a different purpose and mission in 
life -  more allied to UML and that case/modelling world.  <SNIP>

While XMI certainly had PART of its roots in the world of UML - another part
was in metadata management per se.  It's use in the OMG data warehousing
standard (guess what OMG was NOT known for data warehousing either 2 years
ago) is a very good example of its richness for very serious enterprise

I have to agree that XMI is a technology in development - so is XML, XML
Schema etc.

P.S (I was not there in Brussels so some one else may have presented XMI!).
Continued meeting of the minds of EDI experts and OMG metadata experts can
only serve both communities well.

So to summarize : XMI is not just for exchanging UML models.  

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC