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

[Diego Ballvé <diego.ballve@republica.fi>]

Joe, Paul,

Nice to see action in this list. :)

About the "abstract" Core Component, I agree on the need for that.
But I suspect the idea is already covered by DataType - can we see
it like that?? I will try to explain:

Shifting the abstract to DataType, one would first create a
DataType for TaxAmount (I'm not sure about DataType naming rules)
and, with a RIMAssociation (I'm pushing a bit here), one would
connect the ACC to the DataType - the RIMAssociation would be
the BCC, similarly to ACC-ACC RIMAssociation representing ASCC.
You can't reuse the BCC but you can reuse its DataType. That is
already supported by CCTS.

How does that sound?

Regards,
Diego

> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Monday, November 10, 2003 2:55 AM
> To: MACIAS Paul; CCRev
> Subject: [regrep-cc-review] [Further Consideration] Re:
> [regrep-cc-review] Help with clarifying registry handling of CCTS
> 
> 
> 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.