[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: [cam] Core Components Issue: Representation of Aggregate Core Components
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. <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]