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

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

Thanks Monica - I agree with all your thoughts. Here's a bit more
information that I didn't provide in my previous response:

Assuming (at least for the time being) that "Tax. Amount" is a BCC, it
could be based on a Data Type named "FiveDigitAmount" where:

- "FiveDigitAmount" represents a currency whose maximum possible value
is 5 digits (plus 2 decimals), or (using dollars here) $10,000.00;

- Its Content Restriction would stipulate the maximum possible value (or
number of digits) accordingly;

- An alternate name could be "Max10000Amount"; 

- Both names above are devoid of business semantics, as per the CCTS
spec's definition of Data Types, and they can be reused for multiple 

- This general concept of such a Data Type is somewhat akin to a W3C
Schema SimpleType which is of type "xsd:decimal" and facets for maximum
digits;

- In terms of naming, the "FiveDigitAmount" DataType would be based on a
CCT of "Amount. Type" (which "gives it" its "Amount" term), and it would
have 2 Qualifier attributes associated with it - one is "Five", the
other is "Digit". The tricky issue would be maintaining the order of the
slots, so that it is not interpreted as "DigitFiveAmount".

Thoughts?

Thanks,
Joe

"Monica J. Martin" wrote:
> 
> Diego Ballvé wrote:
> 
> >Joe, Paul,
> >
> >Nice to see action in this list. :)
> >
> >About the "abstract" Core Component, I agree on the need for that.
> >But I suspect the idea is already covered by DataType - can we see
> >it like that?? I will try to explain:
> >
> >Shifting the abstract to DataType, one would first create a
> >DataType for TaxAmount (I'm not sure about DataType naming rules)
> >and, with a RIMAssociation (I'm pushing a bit here), one would
> >connect the ACC to the DataType - the RIMAssociation would be
> >the BCC, similarly to ACC-ACC RIMAssociation representing ASCC.
> >You can't reuse the BCC but you can reuse its DataType. That is
> >already supported by CCTS.
> >
> >How does that sound?
> >
> >
> mm1: This sounds much more in line with how a data type restricts or
> bounds the CC. Perhaps this should be further discussed and we could, if
> reasonable, provide some feedback to CC team as there has been quite a
> bit of confusion around Data Types.
> 
> >Regards,
> >Diego
> >
> >
> >
> >>-----Original Message-----
> >>From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> >>Sent: Monday, November 10, 2003 2:55 AM
> >>To: MACIAS Paul; CCRev
> >>Subject: [regrep-cc-review] [Further Consideration] Re:
> >>[regrep-cc-review] Help with clarifying registry handling of CCTS
> >>
> >>
> >>Since I wrote the reply below I've given further consideration to some
> >>of the concepts in <Quote3> below. This is addressed to all
> >>subscribers
> >>on this listserv, as I am continuing the development of our Technical
> >>Note.
> >>
> >>Paul, this would not change any of my general responses to you, but is
> >>rather a bit further down in the weeds.
> >>
> >>Here's the scenario:
> >>
> >>- A user registers a BCC whose Property Term is "Tax" and whose
> >>associated Data Type is "Amount".
> >>
> >>- Without being further associated with an ACC (i.e. without an Object
> >>Class Term), the Dictionary Entry Name for this BCC would be "Tax.
> >>Amount".
> >>
> >>- We would like to reuse this "Tax. Amount" BCC in multiple
> >>scenarios -
> >>that is, we would like to associate it with multiple ACCs.
> >>Once this is
> >>done, an Object Class Term would be added to its Dictionary
> >>Entry Name -
> >>so for example, if it is associated with an ACC whose Object
> >>Class Term
> >>is "Invoice", its Dictionary Entry Name would then be "Invoice. Tax.
> >>Amount".
> >>
> >>So far, so good. Now here is the crux of the issue.
> >>
> >>If we associate "Tax. Amount" with the ACC described above, and assign
> >>the BCC a unique identifier (and definition, etc.), then it cannot be
> >>reused (i.e. it cannot be associated with another ACC because it is
> >>already called "Invoice. Tax. Amount" and is associated with an ACC).
> >>
> >>What if we were to consider "Tax. Amount" a sort of
> >>"abstract" BCC (like
> >>an abstract class) from which other BCCs are derived? Then we could
> >>create Associations from "Tax. Amount" to multiple ACCs as
> >>needed - i.e.
> >>one to the "Invoice. Details" ACC, one to the "Budget. Details" ACC,
> >>etc. This would allow us to avoid registering multiple BCCs as
> >>ExtrinsicObjects.
> >>
> >>We would then represent "concrete" (non-abstract) BCCs using
> >>Associations between the "abstract" BCC (Tax. Amount) and the various
> >>ACCs (Invoice. Details, Budget. Details). Most if not all of the BCC
> >>attributes (Unique Identifier, Definition, etc.) would be
> >>represented as
> >>Slots on the Association.
> >>
> >>The "abstract" Core Component would also have its own
> >>attributes (those
> >>listed in the CCTS - Unique Identifier, Definition, Version, etc.).
> >>
> >>In terms of registration (assuming an empty registry), a user would
> >>first need to register the abstract BCC and an ACC (in any order), and
> >>then create the concrete BCC through an Association.
> >>
> >>Perhaps we could call the abstract BCC a "base BCC", and a
> >>concrete BCC
> >>simply a BCC. We'll also need to consider if these concepts scale for
> >>ACC-to-ACC associations, and - if so - if they make sense.
> >>
> >>Thoughts and comments are welcome and appreciated.
> >>
> >>Thanks,
> >>Joe
> >>
> >>Chiusano Joseph wrote:
> >>
> >>
> >>>Paul,
> >>>
> >>>Great questions - please see comments below:
> >>>
> >>><Quote1>
> >>>Specifically if you have the CC "Invoice.Tax.Amount", that is one
> >>>complete registered object.
> >>></Quote1>
> >>>
> >>>That is correct - "Invoice.Tax.Amount" would be the Dictionary Entry
> >>>Name of the Basic Core Component (BCC) that is registered as an
> >>>ExtrinsicObject. Furthermore, the BCC would have a "Property Term"
> >>>attribute whose value is "Tax", and its related Core Component Type
> >>>(CCT) is "Amount. Type" (we can also say that it is of Data Type
> >>>"Amount"). Finally, the BCC would be a property of
> >>>
> >>>
> >>(contained within) an
> >>
> >>
> >>>ACC called "Invoice. Details", which would have an "Object Class"
> >>>attribute whose value is "Invoice. Details". These attributes, along
> >>>with the Data Type, comprise the Dictionary Entry Name.
> >>>
> >>>
> >>Please note also
> >>
> >>
> >>>that if there were one or more Qualifer Terms they would also become
> >>>part of the Dictionary Entry Name, but there are none in this case.
> >>>
> >>><Quote2>
> >>>Correct me if I'm wrong, we don't discuss registering an "Invoice"
> >>>object class identifier and a separate "Tax.Amount" term and then
> >>>connect them through associations?
> >>></Quote2>
> >>>
> >>>Please pardon some repetition from above. We would register an ACC
> >>>called "Invoice. Details", and this ACC would have an Object Class
> >>>attribute whose value is "Invoice". We would also register
> >>>
> >>>
> >>a BCC called
> >>
> >>
> >>>"Tax. Amount" whose Property Term attribute is "Tax" and
> >>>
> >>>
> >>which is based
> >>
> >>
> >>>on a Data Type of "Amount" (which is further associated
> >>>
> >>>
> >>with a CCT of
> >>
> >>
> >>>"Amount. Type"), and there would be a registry Association
> >>>
> >>>
> >>between the
> >>
> >>
> >>>ACC and BCC. The Dictionary Entry Name "Invoice. Tax. Amount" would
> >>>result from the registry Association (i.e. without the
> >>>
> >>>
> >>Association, the
> >>
> >>
> >>>Dictionary Entry Name could not be derived).
> >>>
> >>><Quote3>
> >>>The latter was raised as an idea for developing a generic
> >>>
> >>>
> >>version of the
> >>
> >>
> >>>Property Term/Representation Term that could be associated to
> >>>many Object Classes.
> >>></Quote3>
> >>>
> >>>Yes - that is exactly what we are intending to do in the
> >>>
> >>>
> >>registry. The
> >>
> >>
> >>>question then becomes: should we retain a single Core
> >>>
> >>>
> >>Component in the
> >>
> >>
> >>>registry called "Tax. Amount" for all ACCs with which it is
> >>>
> >>>
> >>associated,
> >>
> >>
> >>>or have a separate "copy" in the registry for each case? In
> >>>
> >>>
> >>other words,
> >>
> >>
> >>>suppose we have 2 ACCs: "Invoice. Details" and "Budget. Details". We
> >>>also have a Core Component called "Tax. Amount". If we associate the
> >>>Core Component with the "Invoice. Details" ACC, its Dictionary Entry
> >>>Name would be "Invoice. Tax. Amount", while if we associate
> >>>
> >>>
> >>it with the
> >>
> >>
> >>>"Budget. Details" ACC, its Dictionary Entry Name would be
> >>>
> >>>
> >>"Budget. Tax.
> >>
> >>
> >>>Amount". The issue at this point is that there is only one
> >>>
> >>>
> >>Dictionary
> >>
> >>
> >>>Entry Name attribute for the Core Component class (which
> >>>
> >>>
> >>there should
> >>
> >>
> >>>be).
> >>>
> >>>With the first approach (retain a single copy), we would
> >>>
> >>>
> >>need to move
> >>
> >>
> >>>the Dictionary Entry Name to be an attribute of the Association that
> >>>connects the Core Component and ACC; this would allow us to
> >>>
> >>>
> >>retain one
> >>
> >>
> >>>instance in the registry of the "Tax. Amount" Core Component but
> >>>associate it with many ACCs. The problem with this approach is that
> >>>since the Core Component class also has a "Unique
> >>>
> >>>
> >>Identifier" attribute,
> >>
> >>
> >>>we would be assigning a Unique Identifier to something that really
> >>>represents multiple Core Components (i.e. "Invoice. Tax.
> >>>
> >>>
> >>Amount" and.
> >>
> >>
> >>>"Budget. Tax. Amount"). This of course violates the concept of
> >>>uniqueness.
> >>>
> >>>With the second approach (separate copy), we would retain in the
> >>>registry separate ExtrinsicObjects (i.e. a separate Core Component
> >>>instances) for "Invoice. Tax. Amount" and "Budget. Tax.
> >>>
> >>>
> >>Amount". This
> >>
> >>
> >>>would allow them to have separate Unique Identifiers, separate
> >>>Definitions (which they should have), etc. So if a user attempts to
> >>>"assign" an existing Core Component (i.e. a Core Component that is
> >>>already assigned to one ACC) to a new ACC, they should be prompted
> >>>through the user interface to enter a new Definition (and other
> >>>attributes), and a new Unique Identifier should be generated.
> >>>
> >>>Hope that helps,
> >>>Joe
> >>>
> >>>"MACIAS, Paul" wrote:
> >>>
> >>>
> >>>>I need a reminder on how we (ebXML Reg/Rep) are planning
> >>>>
> >>>>
> >>to recommend capturing Core Components in the technical note.
> >> The Department of Navy is developing an update to their
> >>design rules, which draw from CCTS. I'm feeding them the
> >>practical aspects of what to expect from the CCTS technical
> >>note based on the CC subteam discussions. Unfortunately, one
> >>DON member raised a question that I think I know the answer
> >>to, but I couldn't rule out definitively.
> >>
> >>
> >>>>I believe we were capturing the terms of a Core Component
> >>>>
> >>>>
> >>as a single registered item. Specifically if you have the CC
> >>"Invoice.Tax.Amount", that is one complete registered object.
> >> Correct me if I'm wrong, we don't discuss registering an
> >>"Invoice" object class identifier and a separate "Tax.Amount"
> >>term and then connect them through associations? The latter
> >>was raised as an idea for developing a generic version of the
> >>Property Term/Representation Term that could be associated to
> >>many Object Classes.  The flexibility of the registry
> >>specification may allow this, but since it's not the way I
> >>see the CCTS expecting them to be registered I didn't think
> >>it was a method we looked at.  Am I correct?
> >>
> >>
> >>>>NOTE:  I am not endorsing or encouraging any change in
> >>>>
> >>>>
> >>the direction of the CCTS technical note at this time.  Joe
> >>and others put in a lot of work to get the rules nailed down
> >>and I don't want to change coarse now.  I just want to
> >>clarify the approach going into the technical note.
> >>
> >>
> >>>>Thanks,
> >>>>
> >>>>Paul
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>>>                  Name: winmail.dat
> >>>>   winmail.dat    Type: application/ms-tnef
> >>>>              Encoding: base64
> >>>>
> >>>>
> >>>>
> >>>>
> >>--------------------------------------------------------------
> >>----------
> >>
> >>
> >>>>To unsubscribe from this mailing list (and be removed
> >>>>
> >>>>
> >>from the roster of the OASIS TC), go to
> >>http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/
> >>
> >>
> >members/leave_workgroup.php.
> >
> >
> >>  ------------------------------------------------------------------------
> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
> >>
> >>
> >
> >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
> >
> >
> >
> 
> 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