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