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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: [regrep] Final draft recommendations for CC's and Registry -UML/UMM Profile for CCTS


BEDINI Ivan RD-BIZZ-CAE wrote:

I agree with you UML (and XMI) can't be used alone as *standard* object serialization.
It can only provide a good meaning for human interchange that a machine can understand.
The serialization and persistence storage are provided in ebRIM format.


Herein lies the work we did to examine the requirements for the 
serialization.  Logically, it seems that the solution for object 
serialization will place requirements on the object persistence storage 
format.  No one can argue this.

We wanted to look at some very specific items:

1. Is there anything that the eb RIM cannot handle that is needed on the 
wire?  (The answer seems to be no).
2. Does RSS convey the ability to extract a serialization of the object 
complete enough to be used?  (The answer seems to be yes).

The next bit of work was to determine if we should make a binding that 
is dependent upon access to a registry in order to use the CC's and 
BIE's as per UMM and the CCTS methodology.  Do we want to make the one 
official serialization in accordance with RSS or do we want to mandate 
the solution for storage is RIM?  We felt it would be not prudent to 
require that everyone who wants to use CC"s be fluent in eb Registry 
speak and have access to such.   The problem is very simple to address 
if constrained to the CC's and BIE';s themselves, but when adding in the 
element of context and context declarations, it becomes very 
unmanageable IMO.

Answer: My gut feel is that we don't know enough at this point to make 
that decision.  I wanted to ensure that the thinking we put into this 
was captured and given to UN/CEFACT for their consideration.  There is 
no solution mandated in that work - only an approach illustrated that 
may or may not be worth using as a solution. 

If XMI is the on the wire format, then the "things" that will be sent on 
the wire need to be part of the storage format.  You note here that you 
don't think XMI can provide what we need.  I haven't investigated it to 
determine this so far but wonder if you could bring up a few examples of 
where it may fall short? 

Duane

***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********



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