OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [My Interpretation] Re: Question on CCTs vs Data Types


Fred,

Thanks again for your responses - they have been very helpful to us.

<Quote1>
I sense we have the same interpretation of the spec.
</Quote1>

Respectfully, our interpretations appear to be very different (per the
e-mail I just sent a few minutes ago).

<Quote2>
I just am not sure what you mean by "slot".
</Quote2>

By "slot" I mean a "custom" metadata attribute in the registry. This is
the ebXML Registry's mechanism extensibility mechanism - so for example,
if one registered a schema and wanted to include metadata such as "Used
by Federal Agency", they would add a "Slot" in the registry (speaking
very generally) so that this information could be recorded along with
the schema.

<Quote3>
Your observation about basing a DT on another DT and qualifying it
further is fascinating.
</Quote3>

Thanks! (had to separate that one out)

<Quote4>
I think this is the right way to go. Not only for DT's but also for
BIE's. You are correct that that feature is not (yet) supported
explicitly in the CCTS. TBG17 for a start has decided to introduce that
rule, as the CCTS does not forbid it. 
</Quote4>

Yes, our Technical Note will include more inheritance mechanisms as they
make sense, mostly likely to include BIEs as well (haven't yet reached
that point). For example, at the BCC level, we will provide the ability
to register a "Base BCC" such as "Vendor. Code" that can be associated
with multiple ACCs, to yield BCCs such as "PurchaseOrder. Vendor. Code"
and "Invoice. Vendor. Code".

I have been tracking TBG17's progress via the Yahoo! Group, and may
consider joining in sometime after the New Year.

Kind Regards,
Joe

"Fred Blommestein, van" wrote:
> 
> Joe,
> 
> I sent my previous reaction before I saw your last message. Apologies.
> 
> I sense we have the same interpretation of the spec.
> I just am not sure what you mean by "slot".
> 
> Your observation about basing a DT on another DT and qualifying it further is fascinating. I think this is the right way to go. Not only for DT's but also for BIE's. You are correct that that feature is not (yet) supported explicitly in the CCTS. TBG17 for a start has decided to introduce that rule, as the CCTS does not forbid it.
> 
> Fred
> 
>         -----Original Message-----
>         From: Alan.Stitzer@marsh.com [mailto:Alan.Stitzer@marsh.com]
>         Sent: Mon 01/12/2003 20:11
>         To: Fred Blommestein, van
>         Cc:
>         Subject: [My Interpretation] Re: Question on CCTs vs Data Types
> 
> 
> 
>         another one
> 
> 
>         ajs
> 
> 
>         ---------------------- Forwarded by Alan Stitzer/NYC-NY/US/Marsh/MMC on 1 Dec 2003, 14:09  Monday ---------------------------
> 
> 
>         chiusano_joseph@bah.com@Internet on 1 Dec 2003, 13:52 Monday
> 
>         To:    Alan Stitzer; blantz; regrep-cc-review
>         cc:
>         Subject:    [My Interpretation] Re: Question on CCTs vs Data Types
> 
> 
>         Alan,
> 
>         Perhaps this might help us: Here is how my interpretation (correct or
>         perhaps not) of Data Type vs. CCT became more solidifed once I started
>         getting down to the actual registration of the entities in an ebXML
>         Registry:
> 
>         (1) User would register a CCT called "Country_Code" (not "Country. Code,
>         because "Country" is actually a Representation Term Qualifier in this
>         case not a Property Term), with the Supplementary Component attributes
>         included in the registration (code list ID, agency, etc.)
> 
>         NOTE: I found it unncessary to register a separate "Supplementary
>         Component" entity; instead, I represented the attributes from the
>         "Supplementary Component" entity as Slots on the "Country_Code" CCT
> 
>         (2) If user would like to represent a subset of "Country_Code", they
>         would now register a Data Type (which restricts a CCT) called
>         "European_Country_Code"
> 
>         NOTE:
> 
>         - I found it unncessary to register separate "Supplementary Component
>         Restriction" and "Content Component Restriction" entities; instead, I
>         represented the attributes from the "Supplementary Component
>         Restriction" entity as Slots on the "European_Country_Code" Data Type
>         - There was no Content Component Restriction in this case, but if the
>         Data Type were (for example) an amount, there could be a Content
>         Component Restriction
> 
>         - I associated the Data Type in the registry with the "Country_Code" CCT
> 
>         (3) If the user would like to register another more specific set of
>         codes based on the "European_Country_Code" Data Type (e.g.
>         "West_European_Country_Code"), they would register a new Data Type
>         called "West_European_Country_Code" that restricts the
>         "European_Country_Code" Data Type further.
> 
>         NOTE:
> 
>         - I associated the new Data Type in the registry with the
>         "European_Country_Code" Data Type
> 
>         - This possibility (Data Types building on other Data Types) is not
>         mentioned in the CCTS, but seems logical to me
> 
>         Again, this may be totally off base, and if it is I would very much
>         appreciate your expressing that.
> 
>         Thanks,
>         Joe
> 
>         Joseph Chiusano wrote:
>         >
>         > Alan,
>         >
>         > Please feel free to remove the CC Review address when you reply (since
>         > you're not a listserv member, you're getting that error).
>         >
>         > Regarding the attached file: It appears to "span" 2 entities in the
>         > CCTS: Data Type and CCT. By that, I mean it specifies that "Country.
>         > Identifier. Type" (doesn't matter for the purposes of this question
>         > whether it is a Code or Identifier type) is a Data Type, yet it provides
>         > the metadata (Identification Scheme. Identifier, etc.) for a CCT (i.e.
>         > the attributes listed are those of a Supplementary Component, which is
>         > associated with a CCT). How can this be possible, given Figure 7-1 in
>         > the CCTS?
>         >
>         > Thanks in advance for your help,
>         > Joe Chiusano and the Core Components Review SC
>         >
>         > Alan.Stitzer@marsh.com wrote:
>         > >
>         > > Joe,
>         > >
>         > > I get this email bounced back to me:
>         > > regrep-cc-review@lists.oasis-open.org
>         > >
>         > > as taken from the TBG17 initial dictionary, this is what Country_
>         > > Identifier. Type looks like:
>         > >
>         > > (Embedded image moved to file: pic23038.pcx)
>         > >
>         > > ajs
>         > >
>         > > <<< Memo from chiusano_joseph@bah.com@Internet on 01 December, 2003,
>         12:21
>         > > Monday >>>
>         > >
>         > > chiusano_joseph@bah.com@Internet on 1 Dec 2003, 12:21 Monday
>         > >
>         > > To:    Alan Stitzer
>         > > cc:    blantz; regrep-cc-review
>         > > Subject:    Re: Question on CCTs vs Data Types
>         > >
>         > > Thanks Alan. I would like to take your answer a step further, if it's
>         > > ok:
>         > >
>         > > Since "Country_Code" is a Data Type, it has the following CCTS
>         > > requirement:
>         > >
>         > > [S29] Stored Data Types shall have a Core Component Type as their
>         basis.
>         > >
>         > > Given that, we would have the following CCT requirement:
>         > >
>         > > [S19] Core Component Types are a particular category of Core
>         Components.
>         > > As such, stored Core Component Types shall include all Attributes of
>         > > stored Core Components.
>         > >
>         > > Given that, we would have the following "Store Component Components"
>         > > requirement (explanations are snipped):
>         > >
>         > > [S1] Core Components are a particular category of Registry Classes. As
>         > > such, all stored Core Components shall include the following
>         Attributes:
>         > >
>         > > ? Unique Identifier (mandatory)
>         > > ? Version (mandatory)
>         > > ? Dictionary Entry Name (mandatory)
>         > > ? Definition (mandatory)
>         > > ? Usage Rule (optional, repetitive)
>         > >
>         > > What would the value for the "Dictonary Entry Name" attribute be for
>         the
>         > > corresponding CCT? Would it be "Code. Type"? If so, how can one specify
>         > > the "Supplementary Component" attributes for the "Country_Code" Data
>         > > Type (code list ID, agency, etc.) if they are tied to a single CCT
>         > > called "Code. Type"?
>         > >
>         > > Thanks in advance for your help,
>         > > Joe Chiusano and the Core Components Review SC
>         > >
>         > > >
>         > > > Joe,
>         > > >
>         > > > >Is an entity named "Country_Code" a CCT or a Data Type? I interpret
>         it
>         > > > >as a CCT.
>         > > >
>         > > > Without getting into a debate that has raged on and on and on and
>         > > > on....that would be a data type, however, we believe that it is an
>         > > > identifier rather than a code.
>         > > >
>         > > > TBG17 has a defined data type called Country_ Identifier -- which
>         > > restricts
>         > > > the CCT identifier to the "correct" country (aarrgghh) code list.
>         > > >
>         > > > ____________________
>         > > > Alan Stitzer
>         > > > AVP
>         > > > Marsh USA Inc.
>         > > > 1166 Avenue of the Americas
>         > > > New York, NY 10036-2774
>         > > > Phone: (561) 743-1938
>         > > > Fax: (561) 743-1993
>         > > > Internet: Alan.Stitzer@marsh.com
>         > > > ____________________
>         > > >
>         > > > <<< Memo from chiusano_joseph@bah.com@Internet on 01 December, 2003,
>         > > 11:51
>         > > > Monday >>>
>         > > >
>         > > > chiusano_joseph@bah.com@Internet on 1 Dec 2003, 11:51 Monday
>         > > >
>         > > > To:    Alan Stitzer; blantz
>         > > > cc:    regrep-cc-review
>         > > > Subject:    Question on CCTs vs Data Types
>         > > >
>         > > > Mary Kay and Alan,
>         > > >
>         > > > We (the OASIS/ebXML Registry Core Components Review SC) have a
>         question
>         > > > on CCTs vs Data Types that we hope you can answer for us, as I don't
>         > > > believe the answer is clear from the CCTS (or I have misinterpreted
>         the
>         > > > CCTS):
>         > > >
>         > > > Is an entity named "Country_Code" a CCT or a Data Type? I interpret
>         it
>         > > > as a CCT.
>         > > >
>         > > > More details:
>         > > >
>         > > > - According to Gunther's CCT document (XML representations), I
>         believe
>         > > > that Country_Code would be considered a CCT.
>         > > >
>         > > > - The issue underlying the question is that the CCTS lists multiple
>         > > > Supplementary Component attributes (code list ID, agency, etc.) which
>         -
>         > > > I believe - would need to be tied to a specific code list (such as
>         > > > "Country_Code") rather than a generic CCT called "Code. Type".
>         > > >
>         > > > - I'm sure how/why we would register a generic CCT called "Code.
>         Type" -
>         > > > i.e. what values would the attributes (code list ID, agency, etc.)
>         have?
>         > > >
>         > > > - So a more "specific" Country_Code - e.g. European_Country_Code -
>         would
>         > > > be a Data Type (not a CCT), which restricts the CCT called
>         > > > "Country_Code" to inlcude only those codes from European countries.
>         > > >
>         > > > Thanks in advance for your help,
>         > > > Joe Chiusano and the Core Components Review SC
>         > > > (See attached file: Chiusano_Joseph.vcf)
>         > > >
>         > > > To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC,
>         > > blantz@attglobal.net@Internet
>         > > > cc:    regrep-cc-review@lists.oasis-open.org@Internet
>         > > > From:  chiusano_joseph@bah.com@Internet
>         > > (See attached file: Chiusano_Joseph.vcf)
>         > >
>         > > To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC
>         > > cc:    blantz@attglobal.net@Internet,
>         > >        regrep-cc-review@lists.oasis-open.org@Internet
>         > > From:  chiusano_joseph@bah.com@Internet
>         > >
>         > >
>         ------------------------------------------------------------------------
>         > >                           Name: pic23038.pcx
>         > >    pic23038.pcx           Type: PCX Image
>         (application/x-unknown-content-type-pcxfile)
>         > >                       Encoding: base64
>         > >                Download Status: Not downloaded with message
>         (See attached file: Chiusano_Joseph.vcf)
> 
> 
>         To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC, blantz@attglobal.net@Internet,
>                regrep-cc-review@lists.oasis-open.org@Internet
>         cc:
>         From:  chiusano_joseph@bah.com@Internet
> 
> 
> 
> 
> -------------
> Dit e-mailbericht en enige bijlage is vertrouwelijk en
> uitsluitend bestemd voor de geadresseerde(n). Indien u niet
> de geadresseerde bent, mag u deze e-mail of enige bijlage niet
> kopieren of aan derden ter inzage geven of verspreiden.
> Indien u deze e-mail per vergissing heeft ontvangen
> verzoeken wij u de afzender ervan onmiddellijk op de hoogte te
> stellen per e-mail en de betreffende e-mail te vernietigen.
> 
> This e-mail and any attachment is confidential and may
> contain legally privileged information. If you are not the
> intended recipient, please note that this e-mail or any
> attachment may not be copied or disclosed or distributed to
> others. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> --------------
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]