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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Re: UBL, XMI, XSD, RSS, etc


Title:
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



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