[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep-cc-review] [Further Consideration] Re: [regrep-cc-review] Help with clarifying registry handling of CCTS
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:email@example.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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]