Issue #6: Content Components (Final Issue)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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>

CCT Example.doc

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

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

--- 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