[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [REVISITED]Re: [regrep-cc-review] CCTS Spec RIM Mappings [S19] to [S26]
Team,
Here is a revisiting of [S19] to [S26], with our recent discussions
incorporated. Please comment on the proposed handlings marked with
<JMC>.
Thanks,
Joe
[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>
We will simply include all attributes of Core Components with the
Core Component Type (CCTT) ObjectType.
</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>
We could define ExtrinsicObjects for Content Component and Supplementary
Component, and associate these with the pertinent CCT using
Associations.
BIG QUESTION: 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)
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>
Each Secondary Representation Term can be represented using a Slot. For
discussions on cardinality, see "Cardinality" thread.
</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>
This is satisfied by our proposed handling of [S20] through use of
Associations.
</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
Definition - maps to RegistryObject.description
Primitive Type - represent as a Slot; value would be one of: String,
Decimal, Integer, Boolean, Date and Binary (see CCTS p.105, definition
of Primitive Type)
Possible Value - represent as a Slot. For discussions on cardinality,
see "Cardinality" thread.
</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>
See [S20] above, "BIG QUESTION:"
</JMC>
[S26]
Stored Content Components shall include the following Attributes:
- Name
- Definition
- Primitive Type
<JMC>
See [S26].
</JMC>
THE END.
Chiusano Joseph wrote:
>
> 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>
>
> ------------------------------------------------------------------------
> Name: CCT Example.doc
> CCT Example.doc Type: Microsoft Word Document (application/msword)
> Encoding: base64
>
> ------------------------------------------------------------------------
> You 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
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]