[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 withclarifying registry handling of CCTS)
CRAWFORD, Mark wrote:
>Joe,
>
>I really wish you would avoid renaming.
>
I too think we should be careful not to rename unless it is absolutely
necessary. On a related note we need to have a formal channel for
communicating issues we identify in the CCTS specs back to the CCTS team
and have an agreed process for how / when some issues would be
addressed. Thoughts?
>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.
>>
>>
>
>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.
>
>
>
--
Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]