[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue #6: Content Components (Final Issue)
Team, Here is the final issue from the 8/21 Registry TC review - it relates to Content Components, which I believe we don't need to store in the registry. Please see my comments for [S20] below (resending the original e-mail), and please let me know if you have a reason why we should store Content Components in the registry. Thanks, Joe
--- Begin Message ---
- From: "Chiusano Joseph" <chiusano_joseph@bah.com>
- To: CCRev <regrep-cc-review@lists.oasis-open.org>
- Date: Wed, 18 Jun 2003 07:42:20 -0400
Team, Here is the next set of requirements for us: [S19]-[S26]. Below I list each requirement (copy/pasted from the CCTS spec), and - in some cases - a note below marked with <JMC>. Please offer comments/questions regarding how we may map these requirements to the RIM. Thanks, Joe p.77: 7.1.8 Stored Core Component Types [S19] Core Component Types are a particular category of Core Components. As such, stored Core Component Types shall include all Attributes of stored Core Components. <JMC> Can we represent this as "CCTs inherit from BCCs"? </JMC> [S20] Stored Core Component Types shall include one Content Component that defines the Primitive Type and one or more Supplementary Components that give meaning to the Content Component. <JMC> To help us get a better perspective on CCT's/Content Components/Supplementary Components, I've attached an excerpt from Gunter Stuhec's UBL "Common Core Components" draft paper (sent to us by Mark Crawford 2 weeks ago). This shows how these entities are being presented in an XML instantiation. Please see my comments inserted in the document, marked with [JMC]. One big question I have is: do we really need to represent Content Components in the RIM? Or, when an XML representation of a Core Component is created in an XML instance document, wouldn't the "instantiation agent" (the software that creates the XML representation) only need to know: (1) The BCC (for the tag name to be used in the XML document) (2) The value of the BCC (which would not be stored in the registry, as it is data not metadata) (3) The Supplementary Component (for the attribute names to be used in the XML document) (4) The value of the Supplementary Components (ex: currency ID) - (which would not be stored in the registry, as they are data not metadata) Note that there is no entity to represent the value of Supplementary Components (which in my opinion there should not be) - so why do we need an entity (Content Component) to represent the value of a Core Component? If we represent (1) and (3) I think that suffices for us. Thoughts? </JMC> [S21] Stored Core Component Types shall not reflect business meaning. <JMC> This is something that the registry cannot enforce - it is up to users. </JMC> [S22] Stored Core Component Types shall include the following Attributes: - Primary Representation Term (mandatory) - Secondary Representation Term (optional, repetitive) <JMC> How best to represent multiple Secondary Representation Terms using slots? We already touched on this in some exchanges last week. </JMC> p.78: 7.1.9 Stored Supplementary Components [S23] Stored Supplementary Components shall be stored as part of the stored Core Component Type to which they belong, i.e. they shall never exist independently of their owning Core Component Type. <JMC> I believe this is implementation-specific, and should be out of scope of the CCTS spec. </JMC> [S24] Stored Supplementary Components shall include the following Attributes: - Name - Definition - Primitive Type (gives list of possible values - string, decimal, etc.) - Possible Value (optional, repetitive) <JMC> Name - maps to RegistryObject.name (assumes that a Supplementary Component would be represented as a RegistryObject) Definition - maps to RegistryObject.description Primitive Type - would most likely be represented as a Slot; how best to represent a list of valid values for a slot? Possible Value - same issue as with [S22] - how best to represent multiple occurrences? Also: Regarding mandatory/optional attributes - should we represent this in registry? If so, how? </JMC> p.79: 7.1.10 Stored Content Components [S25] Stored Content Components shall be stored as part of the stored Core Component Type to which they belong, i.e. they shall never exist independently of their owning Core Component Type. <JMC> I believe this is implementation-specific, and should be out of scope of the CCTS spec. </JMC> [S26] Stored Content Components shall include the following Attributes: - Name - Definition - Primitive Type <JMC> See [S24]. </JMC>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:vcardYou may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php--- End Message ---
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]