Re: [regrep-cc-review] CCTS Requirement [S7] - p.76

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

<Quote>
S8-S10: especially on page 77, 1st paragraph: (Property Term) shall
serve as basis for Dictionary Entry Name of the Basic or Association
Core Component (note: no ACC) that represents this CC Property.

Based on that, first you have to define a CC Property, Association
or Basic, and then set the Dictionary Entry Name. Now combine S10
with S8 and you should store the CC Property with the Aggregate CC,
not with the Association/Basic CC. What comes first, the egg or the
chicken?? :)
</Quote>

Wow, what a mess!!! I wonder if we need to question the whole concept of
Core Component properties to begin with. If I recall correctly, they
were introduced for this version of the CCTS spec. 

If you look at Figure 7-1 on p.75, it appears that "Basic CC Property"
is just a mechanism to link a BCC with its Data Type. If so, then why
not associate a Data Type directly with a BCC without using a Basic CC
Property? It *appears* to me that the CCTS spec may have gone a bit too
far in specifying implementation rather than concept here, as (I
believe) the spec also does by specifying Association Core Components
(ASCCs).

Does anyone else read this the same way?

I also think requirement [S8] goes a bit far in specifying how entities
should be "stored". What does "stored as part of the Aggregate Core
Component to which they belong" mean? If we store 2 entities in an ebXML
Registry but the registries are federated - one entity in each of 2
registries - and we associate them across registries, is one entity
"stored as part of the other"? Or do they have to be stored in a single
registry to satisfy this (I believe implementation-specific)
requirement?

Joe

Diego Ballvé wrote:
> 
> > Not quite. An ACC has CCProperty which contain Property Terms for its
> > (the ACC's) contained ASCCs/BCCs. This means that a CC has no property
> > term until it gets used (contained) by an ACC. Confusing..
> 
> <JMC>
> Hmmm...I would be interested to know why you interpret the CCTS spec
> this way. My interpretation has always been that Core Components are to
> be stored as entities with their specified attributes, which include
> PropertyTerm. In other words, a registry submitter should be allowed to
> submit a Core Component as a RegistryObject in its own right, without
> that Core Component being "contained" by an Aggregate Core Component.
> This will allow registry submitters to submit all their Core Components
> in advance of creating their Aggregate Core Components if they wish to.
> </JMC>
> 
> I totally agree with you here. It would be stupid if you couldn't first
> define basic parts, then use them for something more complex.
> 
> <JMC>
> Please point me to the requirement in the CCTS spec that states that
> Core Component attributes must not be populated until the Core Component
> is contained by an Aggregate Core Component. I may have missed it.
> </JMC>
> 
> S8-S10: especially on page 77, 1st paragraph: (Property Term) shall
> serve as basis for Dictionary Entry Name of the Basic or Association
> Core Component (note: no ACC) that represents this CC Property.
> 
> Based on that, first you have to define a CC Property, Association
> or Basic, and then set the Dictionary Entry Name. Now combine S10
> with S8 and you should store the CC Property with the Aggregate CC,
> not with the Association/Basic CC. What comes first, the egg or the
> chicken?? :)
> 
> Diego
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