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

["BEDINI Ivan RD-BIZZ-CAE" <ivan.bedini@francetelecom.com>]

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

After, as you, I don't think that XMI can provide the inetrely set of information needed by CCTS to define a CC or BIE. 
Not only the context contraints (even if OCL could be probably used), but all metadata (responsible organisation, version, author, ...) have to be submitted by another way.


Ivan


-----Message d'origine-----
De : Duane Nickull [mailto:dnickull@adobe.com] 
Envoyé : lundi 13 décembre 2004 20:29
À : BEDINI Ivan RD-BIZZ-CAE
Cc : Anders W. Tell; Breininger, Kathryn R; ebXML Regrep (ebXML Regrep)
Objet : Re: [regrep] Final draft recommendations for CC's and Registry - UML/UMM Profile for CCTS

I am not disputing that XMI can be used.  I am sure it can be used.  I am disputing that UML itself (without XMI) can be used and noting that whatever we use, UN/CEFACT should standardize that thing. 

The OMG itself did note that using XMI had some issues albeit most of them are probably irrelevant to our purpose since they are concerned with consistent graphical representation.

UML cannot be parsed by applications unless it is conveyed in some form of electronic format.  UML itself does not (in the UML specification) constrain the exact format for serialization for items like object persistence, object serialization or interchange.

I quote:

"UML is a modeling language for object-oriented software systems with a strong emphasis on a graphical representation.
It is deployed throughout the software development process and there is a wide variety of tools that can be utilized during this process. Tools vary greatly: there is an extensive range geared to design the diagrams, to check the consistency of UML Diagram Interchange 2.0 Adopted Specification models, to store them for persistence or for versioning, for generating code, for preparing demonstrations, presentations or documentation and many more applications."
 
The supplemental specification for UML Diagram Interchange MAY be an answer.  As noted by the OMG, UML itself is NOT sufficient.

"The ability to seamlessly use and combine all of these various tools troublefree is highly valuable and desirable. Accordingly, a mechanism for representing (and hence exchanging) model information was included in the first UML standard. However, the mechanism laid out in UML 1.x merely supports the definition of elements in a model. While this is essential for tools that check the consistency of a model or generate code, this information is not sufficient for graphically oriented tools. This thus excludes a wide variety of tools that make use of graphical information, including UML tools themselves. In this respect, the model interchange mechanism of UML 1.x falls short and the need to correct this deficiency has been recognized and addressed by the OMG."

http://www.omg.org/docs/ptc/03-09-01.pdf

Ivan - I am interested to note how you declare and reconcile the contextual constraints imposed upon BIE's back to both the context declarations and the core components in the registry.  Is there a URI to provide a glimpse to the CC"s and BIE's?

Duane


BEDINI Ivan RD-BIZZ-CAE wrote:

>Duane,
>We already use the XMI format for retrieve CC.
>You can find an exemple of that at :
>http://194.199.139.28/RepXMLWeb/jsp//consult/viewModel.jsp?tab=export&u
>uid=urn:uuid:8f3f7702-ba9d-4af7-ae21-9f9e17ddd120
>
>Here the CC are stored in ebRIM format and retrieved in several formats. XMI is one of that.
>You can import the XMI version in a UML tool and see the CC class diagram. 
>Our feel is that machines are ables to parse a format that is a good human rapresentation and work tool.
>We think that XMI can be a serialisation and we are working on for submit CC directly to the registry in this format.
>
>Regards,
>Ivan
>
>
>
>-----Message d'origine-----
>De : Anders W. Tell [mailto:anderst@toolsmiths.se] Envoyé : lundi 13 
>décembre 2004 19:49 À : Duane Nickull Cc : Breininger, Kathryn R; ebXML 
>Regrep (ebXML Regrep) Objet : Re: [regrep] Final draft recommendations 
>for CC's and Registry - UML/UMM Profile for CCTS
>
>Duane
>
>  
>
>>I mentioned JPG because that is how you rendered UML in the link you 
>>sent out.  UML is not bound to any specific mime type for 
>>serialization.  If you store the stereotypes in *.jpg, I use XMI and 
>>someone else uses *.png or *.svg, our models will not be 
>>interchangeable.  If we all agree on one interchange format like XMI, 
>>then they will.
>>    
>>
>
>I store them using in an XML format generated according to XMI 1.2 principles using UML 1.4 meta model, which is basically standard practice for UML tools.
>
>The JPG is only there since its easier to look at the UML notation than look at the underlying XML file.
>
>  
>
>>One cannot (from an application perspective) store models in UML.  
>>They are stored in another format that gets rendered as UML.  There is 
>>a big difference.
>>    
>>
>
>
>UML is not only a notation, it is also a meta model. Diagrams are only views of model elements in a UML model.
>So yes you can store UML models in (standardized) machine readable format using XMI princples and a UML meta model. The latest OMG development is that now one can also store (logical) diagrams in XML using the DiagramInterchange meta model.
>This paper outlines how to generate SVG from DI models based on (view
>of) a UML model.
><http://www.jeckle.de/files/uml2002.pdf>
>
>/anders
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>  
>

--
***********
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
***********