[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Question on CCTs vs Data Types
Thanks Fred. I believe that these actually cannot be restrictions, because - according to CCTS requirement [S33] (please pardon my citing things that you already know - it's only for our discussion purposes), Stored Supplementary Component Restrictions "shall only be used to restrict the possible values of the Supplementary Component of the Core Component Type on which the Data Type is based". There is no mention of restricting the attributes listed in the PCX file (provided to me by Alan Stitzer), such as Identification Scheme. Identifier, etc. Additionally, Content Component restrictions - according to [S31] - "shall only be used to define format restrictions on the Primitive Type of the Content Component of the Core Component Type on which the Data Type is based.". Again, no sign of this in the PCX file. Lastly, if the PCX file did denote a restriction on the Identifier. Type CCT, that implies that there must be values for these attributes, for the Identifier. Type CCT. That begs the question: What would these values be? For example, what single value could one provide for "Identification Scheme. Identifier" for a CCT called "Identifier. Type"? This is too generic an entity to provide such specific values. The way I interpret things, when factoring in the ebXML Registry architecture, is that the most generic low-level entity that one can register given the entities and metadata in the CCTS is something like "Country_Identifier" - i.e. "Identifier. Type" does not seem to be "registerable" given the entities and metadata in the CCTS. Unless I am severely misinterpreting the CCTS (which I hope I am), I believe that there may be some "metadata misplacement" issues with the CCTS entities. I would be very happy to be proven wrong on this. Kind Regards, Joe "Fred Blommestein, van" wrote: > > Joe, > > In my interpretation a Data Type is based on (further restricts) a CCT. So the entries in the table in your PCX file on Country_ Identifier. Type must be interpreted as restrictions to the values of the Content and Supplemental Components of the CCT Identifier. Type. > > Hope this helpes. > > Fred > > -----Original Message----- > From: Alan.Stitzer@marsh.com [mailto:Alan.Stitzer@marsh.com] > Sent: Mon 01/12/2003 20:10 > To: chiusano_joseph@bah.com; Fred Blommestein, van > Cc: blantz@attglobal.net > Subject: Re: Question on CCTs vs Data Types > > > > Fred, > > can you help me out here..... > > This is what Joe is questioning: > > (Embedded image moved to file: pic14720.pcx) > > ajs > > > > > <<< Memo from chiusano_joseph@bah.com@Internet on 01 December, 2003, 13:37 > Monday >>> > > > chiusano_joseph@bah.com@Internet on 1 Dec 2003, 13:37 Monday > > To: Alan Stitzer > cc: blantz; regrep-cc-review > Subject: Re: Question on CCTs vs Data Types > > > 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 > > > > 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 > > > > > ------------- > 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]