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

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

Since I wrote the reply below I've given further consideration to some
of the concepts in <Quote3> below. This is addressed to all subscribers
on this listserv, as I am continuing the development of our Technical
Note.

Paul, this would not change any of my general responses to you, but is
rather a bit further down in the weeds.

Here's the scenario:

- A user registers a BCC whose Property Term is "Tax" and whose
associated Data Type is "Amount". 

- Without being further associated with an ACC (i.e. without an Object
Class Term), the Dictionary Entry Name for this BCC would be "Tax.
Amount".

- We would like to reuse this "Tax. Amount" BCC in multiple scenarios -
that is, we would like to associate it with multiple ACCs. Once this is
done, an Object Class Term would be added to its Dictionary Entry Name -
so for example, if it is associated with an ACC whose Object Class Term
is "Invoice", its Dictionary Entry Name would then be "Invoice. Tax.
Amount".

So far, so good. Now here is the crux of the issue.

If we associate "Tax. Amount" with the ACC described above, and assign
the BCC a unique identifier (and definition, etc.), then it cannot be
reused (i.e. it cannot be associated with another ACC because it is
already called "Invoice. Tax. Amount" and is associated with an ACC).

What if we were to consider "Tax. Amount" a sort of "abstract" BCC (like
an abstract class) from which other BCCs are derived? Then we could
create Associations from "Tax. Amount" to multiple ACCs as needed - i.e.
one to the "Invoice. Details" ACC, one to the "Budget. Details" ACC,
etc. This would allow us to avoid registering multiple BCCs as
ExtrinsicObjects.

We would then represent "concrete" (non-abstract) BCCs using
Associations between the "abstract" BCC (Tax. Amount) and the various
ACCs (Invoice. Details, Budget. Details). Most if not all of the BCC
attributes (Unique Identifier, Definition, etc.) would be represented as
Slots on the Association.

The "abstract" Core Component would also have its own attributes (those
listed in the CCTS - Unique Identifier, Definition, Version, etc.).

In terms of registration (assuming an empty registry), a user would
first need to register the abstract BCC and an ACC (in any order), and
then create the concrete BCC through an Association.

Perhaps we could call the abstract BCC a "base BCC", and a concrete BCC
simply a BCC. We'll also need to consider if these concepts scale for
ACC-to-ACC associations, and - if so - if they make sense.

Thoughts and comments are welcome and appreciated.

Thanks,
Joe

Chiusano Joseph wrote:
> 
> 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.
> 
>   ------------------------------------------------------------------------
> 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