Re: [regrep-cc-review] Help with clarifying registry handling of CCTS

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

Paul,

Great questions - please see comments below:

<Quote1>
Specifically if you have the CC "Invoice.Tax.Amount", that is one
complete registered object.  
</Quote1>

That is correct - "Invoice.Tax.Amount" would be the Dictionary Entry
Name of the Basic Core Component (BCC) that is registered as an
ExtrinsicObject. Furthermore, the BCC would have a "Property Term"
attribute whose value is "Tax", and its related Core Component Type
(CCT) is "Amount. Type" (we can also say that it is of Data Type
"Amount"). Finally, the BCC would be a property of (contained within) an
ACC called "Invoice. Details", which would have an "Object Class"
attribute whose value is "Invoice. Details". These attributes, along
with the Data Type, comprise the Dictionary Entry Name. Please note also
that if there were one or more Qualifer Terms they would also become
part of the Dictionary Entry Name, but there are none in this case.

<Quote2>
Correct me if I'm wrong, we don't discuss registering an "Invoice"
object class identifier and a separate "Tax.Amount" term and then
connect them through associations? 
</Quote2>

Please pardon some repetition from above. We would register an ACC
called "Invoice. Details", and this ACC would have an Object Class
attribute whose value is "Invoice". We would also register a BCC called
"Tax. Amount" whose Property Term attribute is "Tax" and which is based
on a Data Type of "Amount" (which is further associated with a CCT of
"Amount. Type"), and there would be a registry Association between the
ACC and BCC. The Dictionary Entry Name "Invoice. Tax. Amount" would
result from the registry Association (i.e. without the Association, the
Dictionary Entry Name could not be derived).

<Quote3>
The latter was raised as an idea for developing a generic version of the
Property Term/Representation Term that could be associated to
many Object Classes. 
</Quote3>

Yes - that is exactly what we are intending to do in the registry. The
question then becomes: should we retain a single Core Component in the
registry called "Tax. Amount" for all ACCs with which it is associated,
or have a separate "copy" in the registry for each case? In other words,
suppose we have 2 ACCs: "Invoice. Details" and "Budget. Details". We
also have a Core Component called "Tax. Amount". If we associate the
Core Component with the "Invoice. Details" ACC, its Dictionary Entry
Name would be "Invoice. Tax. Amount", while if we associate it with the
"Budget. Details" ACC, its Dictionary Entry Name would be "Budget. Tax.
Amount". The issue at this point is that there is only one Dictionary
Entry Name attribute for the Core Component class (which there should
be). 

With the first approach (retain a single copy), we would need to move
the Dictionary Entry Name to be an attribute of the Association that
connects the Core Component and ACC; this would allow us to retain one
instance in the registry of the "Tax. Amount" Core Component but
associate it with many ACCs. The problem with this approach is that
since the Core Component class also has a "Unique Identifier" attribute,
we would be assigning a Unique Identifier to something that really
represents multiple Core Components (i.e. "Invoice. Tax. Amount" and.
"Budget. Tax. Amount"). This of course violates the concept of
uniqueness.

With the second approach (separate copy), we would retain in the
registry separate ExtrinsicObjects (i.e. a separate Core Component
instances) for "Invoice. Tax. Amount" and "Budget. Tax. Amount". This
would allow them to have separate Unique Identifiers, separate
Definitions (which they should have), etc. So if a user attempts to
"assign" an existing Core Component (i.e. a Core Component that is
already assigned to one ACC) to a new ACC, they should be prompted
through the user interface to enter a new Definition (and other
attributes), and a new Unique Identifier should be generated.

Hope that helps,
Joe

"MACIAS, Paul" wrote:
> 
> I need a reminder on how we (ebXML Reg/Rep) are planning to recommend capturing Core Components in the technical note.  The Department of Navy is developing an update to their design rules, which draw from CCTS. I'm feeding them the practical aspects of what to expect from the CCTS technical note based on the CC subteam discussions. Unfortunately, one DON member raised a question that I think I know the answer to, but I couldn't rule out definitively.
> 
> I believe we were capturing the terms of a Core Component as a single registered item. Specifically if you have the CC "Invoice.Tax.Amount", that is one complete registered object.  Correct me if I'm wrong, we don't discuss registering an "Invoice" object class identifier and a separate "Tax.Amount" term and then connect them through associations? The latter was raised as an idea for developing a generic version of the Property Term/Representation Term that could be associated to many Object Classes.  The flexibility of the registry specification may allow this, but since it's not the way I see the CCTS expecting them to be registered I didn't think it was a method we looked at.  Am I correct?
> 
> NOTE:  I am not endorsing or encouraging any change in the direction of the CCTS technical note at this time.  Joe and others put in a lot of work to get the rules nailed down and I don't want to change coarse now.  I just want to clarify the approach going into the technical note.
> 
> Thanks,
> 
> Paul
> 
> 
> 
> 
>   ------------------------------------------------------------------------
>                   Name: winmail.dat
>    winmail.dat    Type: application/ms-tnef
>               Encoding: base64
> 
>   ------------------------------------------------------------------------
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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