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: [Fwd: [cam] Core Components Issue: Representation of AggregateCore Components]


Response from David Webber to the message I sent to the CAM listserv
this morning. Please keep in mind that he is speaking from a CAM point
of view. :)


Joe,

Thanks for bringing this matter to our attention.

Making separate instances IMHO defeats the purpose of having
core components in the first place!

There should only be one.

Fortunately the CAM specification gives you the ability to 
have the parent element name be whatever you want,
while allowing the children to be a "set" that gets included in.

There are many other tools CAM provides - both a simple
<include> mechanism and a more sophisticated <import>
approach, or ability to place the structure choices in-line
and select based on context. 

Also - notice that UID places a significant enabler in this,
(what registry calls ExternalID) since the UUID cannot
be used to do the association (it lacks ability to version 
and also show relation between use (crosswalks) across
multiple document instances).

Managing CONTEXT is also vital.  You need to have a way
in XML to capture the context triggers - and then drive the 
assembly off those.  Again CAM provides that.  This gives
you the "bridge" betwen your CCTS ontology and the actual
business domain (community of interest) ontology.

Now that you appear to have the CCTS / RIM model working,
I think it would be an excellent next step to show how to
use CAM along with this to produce a full production 
environment with assembly of transaction content married
to the CCTS model.   And the XML driven mechanisms
that go into the Registry along with the CAM templates to
build that.

Thanks, DW.
==========================================================
Message text written by "Chiusano Joseph"
>We have a current issue that affects assembly of schemas from components
that I would like to (on behalf of the subcommittee) run by you if I
may. The bottom line issue is: If we derive an Aggregate Core Component
(ACC) from another ("base") Aggregate Core Component, should the "base"
and "derived" ACC each be a separate entity in the registry, with its
own unique ID? Or should they be one entity with additional attributes
added to it? If this isn't clear, the example below will clarify.

Suppose we have an ACC called "Address. Details" - it contains the usual
address information (street, city, etc.) We want to create several other
"related" (derived) ACCs from this "base" ACC, and name them more
specifically (i.e. with more semantic detail) - for example,
"ResidenceAddress. Details", "OfficeAddress. Details", etc.

Each of these "derived" ACCs would have the same properties and content
as the "base" ACC - the only exception is their name.
<



begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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