No Subject

<Quote>
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)
</Quote>

Joe

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: WINWORD File (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
--------------64508DAF4258C78BA86DBF2F
Content-Type: text/x-vcard; charset=us-ascii;
 name="Chiusano_Joseph.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Joseph Chiusano
Content-Disposition: attachment;
 filename="Chiusano_Joseph.vcf"

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

--------------64508DAF4258C78BA86DBF2F--