[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
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? > > mm1: This sounds much more in line with how a data type restricts or bounds the CC. Perhaps this should be further discussed and we could, if reasonable, provide some feedback to CC team as there has been quite a bit of confusion around Data Types. >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. >> >> > >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]