Re: UBL, XMI, XSD, RSS, etc

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
The people building CC libraries will (in theory) be producing UML
models of their data structures.  RSS is looking for XML expressions of
that (i think this is what you mean by 'serialisation').  There was a
CEFACT group (heading by David Webber) called CCR (Core Component
Realisation) whose charter appears to be to do this transformation.  

Farrukh and Joe, how do you and the RSS team see this fitting togther?
</Quote>

Tim, you are absolutely correct in the meaning of XML serialisation
above. 

Regarding CCR: One component (generic sense) of CCR called "CRI"
(Component Registry Interface) has been submitted by David Webber for
consideration for our Core Component XML Serialization effort. As part
of our plan, we will make an assessment (before end of June, as I am
proposing) as to the viability of using CRI as a Core Component XML
Serialization format. If we find it to be non-viable, we will create our
own serialization format instead.

Joe

> Tim McGrath wrote:
> 
> i think this thread is heading in the direction of work that Bill
> Burcham and Dave Carlson have been working on within UBL.  That is,
> UML -> UBL transformations (and vice versa). Dave has literally
> 'written the book' on UML<->XML modeling.
> (http://www.xmlmodeling.com/).
> 
> I actually see the value of the UML within UBL in two ways:
> firstly, as a means of describing a conceptual model from which many
> physical models (various document, eg. Purchase Order, of various
> syntaxes, e.g. EDIFACT or XSD) can be generated (as Steve says). The
> most significant one to UBL is the XSD form.  Bill Burcham has been
> experimenting with automating this generation. In this capacity, the
> conceptual UBL UML model and the physical UBL XSD will not be
> equivalent.  This is because of syntactical requirements for  document
> markup/XML/XSD.  That is why we say the XSD is the normative UBL form.
> 
> 
> secondly, as a means of subsequently presenting document data
> structures (such as Purchase Orders, etc.) in a way that analysts can
> more easily comprehend than by reading schemas. Dave has a tools that
> does this 'automagically'. in which case they are again not
> necessarily equivalent because the UML does not need all the XSD
> metadata.
> 
> however, it also raises some intriguing contradictions within the
> current RSS, and CCTS architecture.  The CCTS expects its CC and BIEs
> to be described using the UMM recommended syntax (i.e. the UML).  The
> people building CC libraries will (in theory) be producing UML models
> of their data structures.  RSS is looking for XML expressions of that
> (i think this is what you mean by 'serialisation').  There was a
> CEFACT group (heading by David Webber) called CCR (Core Component
> Realisation) whose charter appears to be to do this transformation.
> 
> Farrukh and Joe, how do you and the RSS team see this fitting togther?
> 
> PS I have added the UBL Library Content team to this thread as it is
> relevant to our work on CCTS storage compliance.
> 
> Steve Capell wrote:
> 
> > Farrukh,
> >
> > I agree - I was not suggesting that XMI should be he serialisation
> > format.  As you point out, we got aout 200 lines of XML for just one
> > little class diagram.  I think that XSD and UBL naming & design
> > rules
> > would be much better.  The reaon I was talking about XMI is:
> >
> > 1       Most developers of business documents start with UML
> > information
> > models (at least the few in Australia that I am familiar with do).
> > They
> > will then create XSD or DTD or even EDIFACT from those UML models.
> > 2       If we want to encourage registry population with information
> > models (CCs & BIEs) then we need to provide tools to help them do
> > it.
> > Maybe the tools should translate XSD to ebXML RSS but it seemed to
> > me
> > that if the "master" was the UML model then why not create all other
> > representations from that.
> >
> > I have not looked into XMI close ly enough to understand whether it
> > can
> > store all the information required and hence whether there would be
> > any
> > information loss going between XSD and XMI.
> >
> > Regards
> >
> > Steve Capell
> > RedWahoo
> > Sydney, Australia
> > Tel : +61 410 437854
> >
> >
> > -----Original Message-----
> > From: Farrukh Najmi [mailto:farrukh.najmi@sun.com]
> > Sent: Tuesday, 27 May 2003 2:35 AM
> > To: Steve Capell
> > Cc: 'Chin Chee-Kai'; 'Chiusano Joseph'; 'Tim McGrath'; 'Brendan
> > Kelly'
> > Subject: Re: UBL, XMI, XSD, RSS, etc
> >
> >
> > I have looked into XMI some time back. XMI is appropriate for a
> > canonical representation of UML models. As uch UML modeling tools
> > should
> >
> > (and often do) use it as their native format for storing UML model.
> >
> > XMI is inappropriate for being used as a serialization format for CC
> > BIEs or UBL docs. It is tool low level, obtuse and verbose for that.
> > I
> > would advise strongly against XMI as a serialization format. I can
> > also
> > all but assure you that XMI will not be the format for CC BIE
> > serialization.
> >
> > Steve Capell wrote:
> >
> >
> >
> >> Hello all,
> >>
> >> I've been doing a bit more research.
> >>
> >> It seems to me that the best format for maintenance of business
> >> document meta-data is UML.  Most UML tools permit the export of
> >> UML
> >>
> >>
> > data in a
> >
> >
> >> standard format (XMI).   I am guessing that your generation tool
> >> basically transforms XMI to XSD (hard coded?, using XSLT?,
> >> other?).
> >>
> >> I think our preferred approach for management of regsitry data is
> >> to
> >> use a UML tool as the primary reference and then to create
> >> regsitry
> >> update schema by transforming XMI to RSS.  So to make my life
> >> easy, I
> >> basically need four XSLT:
> >>
> >> XSLT for XMI -> XSD
> >> XSLT for XSD -> XMI
> >> XSLT for XMI -> RSS
> >> XSLT for RSS -> XMI
> >>
> >> So a couple of questions:
> >>
> >> 1       Do you know if there would be any significant information
> >> loss
> >> going to / from UML models represented by XMI?
> >> 2       Do you have an XMI representation of the UBL library that
> >> we
> >> could use as the source data for regsitry population?
> >> 3       Do you know if anyone has already built these
> >> transformation
> >> schema?
> >>
> >> Regards,
> >>
> >> Steve Capell
> >> RedWahoo
> >> Sydney, Australia
> >> Tel : +61 410 437854
> >>
> >>
> >> -----Original Message-----
> >> From: Chin Chee-Kai [mailto:cheekai@softml.net]
> >> Sent: Tuesday, 6 May 2003 6:22 PM
> >> To: UBL; UBL Public Comments
> >> Subject: [ubl] UBL 0p70 Common Aggregate Types Java Classes
> >>
> >>
> >> Dear All,
> >>
> >> Java classes, both source codes and compiled class files, based on
> >> the
> >> 92 types found in UBL 0p70 Common Aggregate Types
> >> (UBL_Library_0p70_Reusable.xsd and CoreComponentTypes.xsd) are now
> >> available at:
> >>
> >>         http://SoftML.Net/jedi/ubl/sw/java
> >>
> >> This work is very preliminary.  Nevertheless, the java window
> >> component functions will probably help in experimenting with the
> >> UBL
> >> types, and to simplify data entry and generating XML node files
> >> and
> >> document files from tailored data.
> >>
> >>
> >>
> >> Best Regards,
> >> Chin Chee-Kai
> >> SoftML
> >> Tel: +65-6820-2979
> >> Fax: +65-6743-7875
> >> Email: cheekai@SoftML.Net
> >> http://SoftML.Net/
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> --
> regards
> tim mcgrath
> phone: +618 93352228
> postal: po box 1289   fremantle    western australia 6160
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard