RE: [regrep-cc-review] How Should UML Be Treated? (Was: Re: [regrep-cc-review] Kickoff!)

["MACIAS, Paul" <PMACIAS@lmi.org>]

Joe,

Ah, I think I know what you are getting at.  Mind if I try to rephrase the question to see if I've got a grasp on the issue?

To meet the requirement on CCTS p.65 do we have to ensure that the Table 6-1 information is capable of being captured as part of the UML object's metadata in the registry, or do we expect that the information would be part of the UML object negating the need for the registry to capture some or all of the Table 6-1 information?

If that is the proper question, then my gut reaction is to suggest that we ensure that the registry is capable of capturing the Table 6-1 information and leave it to the implementer/users as to whether they also include the data in the UML object of the repository.  I just think the RIM provides more control over what goes into the registry than what goes in the repository.

If I'm off base on this, please let me know.

Paul

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Thursday, June 05, 2003 4:34 PM
To: MACIAS, Paul
Cc: David RR Webber - XML ebusiness; Diego Ballvé;
regrep-cc-review@lists.oasis-open.org; CRAWFORD, Mark
Subject: Re: [regrep-cc-review] How Should UML Be Treated? (Was: Re:
[regrep-cc-review] Kickoff!)


Paul,

All good questions - I am honestly not sure. Here's another way to
examine the issue:

CCTS p.56 states (under "6.15 Catalogue of Core Components"):

<CCTS>
This catalogue must convey the full details of each Core Component
consistent with how those components are stored as UML objects in the
registry/repository.
</CCTS>

So my question is: What would a UML object of a Core Component look
like?

Joe

"MACIAS, Paul" wrote:
> 
> Joe,
> 
> Is this something that can be left up to the implementer?  I honestly do not know enough about what implementers and users of CC UML representations would want/expect.  Do "we" (as a team) have knowledge or access to resources that can help guide us on the "if" and "how" we should address the issue?  Sort of a pros and cons of what happens if we leave it up to the implementer or some other spec to address.  And if we should address the issue, what are the pros and cons of the approaches.
> 
> Thanks,
> 
> Paul
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, June 05, 2003 2:06 PM
> To: David RR Webber - XML ebusiness
> Cc: Diego Ballvé; regrep-cc-review@lists.oasis-open.org; CRAWFORD, Mark
> Subject: [regrep-cc-review] How Should UML Be Treated? (Was: Re:
> [regrep-cc-review] Kickoff!)
> 
> <Quote>
> That's why I'm very reluctant to engineer something from UML to Registry
> - where there is a "then a miracle happens" in between.
> </Quote>
> 
> I think that now is a good time to ask: How should the UML model of a
> Core Component be treated by the registry? IOW, is it simply an
> ExtrinsicObject whose metadata would be compliant with the CCTS spec?
> Or, would the metadata specified in the CCTS reside *inside* the UML
> model as part of its definition?
> 
> I believe it's the former - but David's comment made me see the need to
> clarify.
> 
> Joe
> 
> David RR Webber - XML ebusiness wrote:
> >
> > Diego,
> >
> > Great posting - all makes sense.  Can you please go have a look
> > at the XML in the following CEFACT document for me?
> >
> > It's out at this link:
> >
> >  http://cam.swiki.net/.uploads/documents/CRI/CRI-Nov-2001.ZIP
> >
> > This was the "magic" that we built previously.  It got complicated
> > as it was trying to handle the assembly as well.  If you 'ignore' that
> > peice - and just look at the noun / codelist pieces - and assume
> > we'll handle the aggregation separately - and then compare this
> > to what you have done already with your CC/BIEs - I'd be
> > very interested in your feedback.
> >
> > The synergy needed in my opinion is - cleverly leveraging the
> > existing RIM plus good XML 'containers' for the atomic
> > components of the vocabulary needs.
> >
> > While I hate to go "backwards" at this - by looking at XML before
> > we get the requirements sets - I think in this case - its instructive
> > to learn from what has gone before - so as we do not lock
> > ourselves into a path that is potentially a cul-de-sac.
> >
> > That's why I'm very reluctant to engineer something from UML
> > to Registry - where there is a "then a miracle happens" in
> > between.  My sense is - if it were that easy - it would have been
> > done already - and things like xUML and iUML show us that
> > researchers are still trying to grapple with the fundamentals
> > there - not a place for the unwary to tread!
> >
> > And that brings us back to having a clear and consistent
> > set of XML serialization that can be readily understood and
> > populated - not just from UML - but any open model environment
> > or dictionary.
> >
> > Then as you mention there are 'little' details like being able
> > to have localization support built-in - key for Europe needs.
> >
> > Thanks, DW.
> > =======================================================
> > Message text written by Diego Ballvé
> > >
> > David, you mentioned performance as an issue against using existing
> > registry constructs, due to traversing nodes and so on - and I can
> > tell you that I've experienced this issues in practice - but I believe
> > you would not be able to put all the information you need into a
> > single chunk of XML (when working with Core Components), unless the
> > registry would do some magic and combine all the parts you need into
> > this document and return it to you. I might be missing something, but
> > this is how I see it till now.
> >
> > <