[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
Thanks Diego - the list has been quiet only because we've completed our analysis of the CCTS spec. As questions come up during my work on the Technical Note, I'll forward them as appropriate to solicit feedback. According to CCTS, "Tax. Amount" should be a BCC rather than a Data Type. Here is some supporting information: (1) P.12 Example: "BirthDate" is represented as a BCC in the p.12 example (the explanation that states "Data Type" is a typo), so it would seem that "Tax. Amount" should also be thought of as a BCC. (2) Also, Figure 4-1 (p.14) represents Data Types as being "without business semantics" - but "Tax. Amount" definitely has business semantics. So this further supports the notion of "Tax. Amount" being represented as a BCC. (3) Also, on p.28 ("Example" box), it states: "Because both the existing Basic Business Information Entity of Invoice. Total_ Tax. Amount and the desired Basic Business Information Entity of Order. Total_ Tax. Amount share strong similarities-they are the same Property and share a specific Data Type, but are applied to different Object Classes-…" The reference to "Property" above would be the Property Term that is common between the BCCs - "Tax" (note that "Total" would be a Property Term Qualifier). This means that the Data Type would be represented by the Representation Term of "Amount" - so in this example, "Total_Tax. Amount" does not represent a Data Type, it represents a BCC (of course we would prepend the Object Class Term value to the Dictionary Entry Name for the BCC, as shown above). So this means that one should be able to reuse the "base BCC" in multiple scenarios - i.e. with multiple ACCs, and subsequently for multiple BBIEs that are potentially contained within multiple ABIEs. If you interpret any of this differently, please let me know. Thanks, Joe Diego Ballvé wrote: > > 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:firstname.lastname@example.org] > > 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.
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:email@example.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard