Re: [regrep-cc-review] [Further Consideration] Re: [regrep-cc-review] Help with clarifying registry handling of CCTS

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<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.
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