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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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

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


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.



-----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!)

That's why I'm very reluctant to engineer something from UML to Registry
- where there is a "then a miracle happens" in between. 

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


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

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