[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep-cc-review] Renaming "Data Types" (Was Re: [regrep-cc-review] [Further Consideration] Re: [regrep-cc-review] Help with clarifying registry handling of CCTS)
Joe, I really wish you would avoid renaming. This is a classic trap that standards efforts fall into. Despite the note, people will be confused as to what you mean. Better to have a note that reinforces that a datatype is a restriction as identified in its CCTS definition. Mark > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: Tuesday, November 11, 2003 8:19 PM > To: MACIAS, Paul; Diego Ballvé; CCRev > Subject: [regrep-cc-review] Renaming "Data Types" (Was Re: > [regrep-cc-review] [Further Consideration] Re: [regrep-cc-review] Help > with clarifying registry handling of CCTS) > > > Given the general confusion around the concept of Data Types, > I've been > toying with the idea of renaming them for our Technical Note as "Core > Component Type Restrictions" (CCTR), which is what they really are. I > think that much of the confusion stems from the fact that folks > (justified or not) think of a "Data Type" as a primitive type such as > string, integer, etc. while our Data Types are much richer. > > I will include clear instructions within the Technical Note regarding > this mapping (Data Type --> CCTR). If anyone has a strong objection to > this*, please let me know. > > Thanks, > Joe > > *"because it's not that way in the CCTS spec" will not be > considered to > be an acceptable objection. ;) > > Chiusano Joseph wrote: > > > > <Quote> > > A registry manager may want to ensure that the contextual > definitions of > > concrete BCCs like "Invoice.Tax.Amount" and > "Budget.Tax.Amount" do not > > stray too far from a common definition for "tax.Amount". > > </Quote> > > > > Well said, Paul. Further supporting that, it's also possible that a > > registry manager could add Slots to "Tax. Amount" for > further metadata > > attributes as needed, so it would be important to have a single > > representation of "Tax. Amount" in the registry that could > be utilized > > in various scenarios. > > > > Joe > > > > "MACIAS, Paul" wrote: > > > > > > Joe, > > > Thanks for clarifying the registry representation. That > was a big help. > > > > > > Joe and Diego, > > > I think I agree with Joe's concept of the abstract BCC > entry. If I'm understanding correctly, I like the idea that > the abstract BCC will allow for a single generic definition > for concepts such as "tax.Amount". A registry manager may > want to ensure that the contextual definitions of concrete > BCCs like "Invoice.Tax.Amount" and "Budget.Tax.Amount" do not > stray too far from a common definition for "tax.Amount". > > > Thought? > > > > > > -Paul > > > > > > -----Original Message----- > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > > Sent: Monday, November 10, 2003 9:08 AM > > > To: Diego Ballvé > > > Cc: MACIAS, Paul; CCRev > > > 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: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. > > > > "MACIAS, Paul" wrote: > > > > > > Joe, > > > Thanks for clarifying the registry representation. That > was a big help. > > > > > > Joe and Diego, > > > I think I agree with Joe's concept of the abstract BCC > entry. If I'm understanding correctly, I like the idea that > the abstract BCC will allow for a single generic definition > for concepts such as "tax.Amount". A registry manager may > want to ensure that the contextual definitions of concrete > BCCs like "Invoice.Tax.Amount" and "Budget.Tax.Amount" do not > stray too far from a common definition for "tax.Amount". > > > Thought? > > > > > > -Paul > > > > > > -----Original Message----- > > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > > Sent: Monday, November 10, 2003 9:08 AM > > > To: Diego Ballvé > > > Cc: MACIAS, Paul; CCRev > > > 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: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]