[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl] Re: [ubl-ndrsc] Proposal 3 in our CCTS feedback
Ooh! Mikey likes it! Thanks, Tim, for doing the research on this. Tim McGrath wrote: > Before we get too confrontational and Arofan starts opening the > armoury, let us take stock of what ISO 11179 says and how it has been > interpreted for CCTS. > > ISO11179-5 (many thanks to Mark who posted this.. > http://lists.oasis-open.org/archives/ubl-lcsc/200201/msg00020.html ) > makes three key points about representation terms: > 1. A representation term is a component of a data element name which > describes the form of representation of the data element. > 2. Each term is developed from a controlled word list or a taxonomy. > 3. This term describes the form of the set of valid values of a data > element. > > The CCTS states: > "A representation term defines the type of valid values for an > information entity. " (CCTS lines 1116 and 1239) and "The type of > valid values for a Basic Core Component." (CCTS Definition of Terms > line 2167) > This changes "the form of the set of"(point 3.) to "the type of". It > is actually quite a significant difference that dilutes the meaning of > ISO11179 and hence leads into the need for CC Types to be defined as well. > > So i am not convinced that CCTS is "using RT as defined in ISO11179" > as sacredly as Mike suggested - they have interpreted the definition > to suit their application. What we are proposing is a change in this > interpretation. I think they were nearer to the definition we mean > with ... > "The Representation Term is the part of a Core Component name that > describes the form of valid values in which the business information > is expressed in a data item" (CCTS line 1313) > > In fact, looking at this again, I wonder if just asking them to adopt > the original ISO 11179 definition is what we really mean!?? > > > > > > Gregory, Arofan wrote: > >> Bill: >> >> I will play devil's advocate here for a moment. >> >> ISO 11179 is a sacred cow, and "Representation Term" is the thing >> that connects the CC work to 11179. >> >> CCT was invented by the CC group as a convenience, to describe the >> supporting properties of an RT. >> >> If you apear to be messing with RTs (say, by relegating them to an >> aspect of the naming conventions while replacing their technical >> function) then you will be violating the sacred donkey (ooops - >> sacred cow!) >> >> It's a damned-if-you-do & damned-if-you-don't situation. I recommend >> that we stick to our guns, and point out that CCTs are unneeded, and >> that RTs are both needed and need to be specifically extended and >> clarified for their application here. >> >> We do, after all, have some smart people in positions of power on the >> CC editing team, and they are ultimately the ones who will have to >> make it all fit together. I think we should submit what Eve has proposed. >> >> Cheers, >> >> Arofan >> >> -----Original Message----- >> From: Burcham, Bill [ mailto:Bill_Burcham@stercomm.com ] >> Sent: Thursday, April 25, 2002 9:54 AM >> To: ubl-ndrsc@lists.oasis-open.org >> Subject: RE: [ubl-ndrsc] Proposal 3 in our CCTS feedback >> >> >> I agree with Mike (that the UN folks might have strong reactions to >> redefining "RepresentationTerm") and I've got an alternative that >> fits with >> ISO 11179 and gives us a single set of semantic primitives at the >> expense of >> possibly running afoul of the "original intent of Representation >> Terms" from >> the old days of ebXML. >> >> Why don't we keep Core Component Type in the model and make it stand >> for the >> "semantic primitives" (rather than throwing out CCT and keeping RT). >> Let's >> keep Representation Term as part of the dictionary entry name. >> >> ISO 11179 is a standard for naming "data elements". Think: ** global >> variables in a big ole FORTRAN program ** That standard gives no clear >> guidance on naming types (which is what CC's, BCC's, ACC's, BIE's, >> ABIE's, >> BBIE's are), nor does it give clear guidance on the relationship between >> types and data elements. (it does mention that it is applicable to >> naming >> "data concepts" but on the mapping of those to classes in OO languages, >> structures in languages like Pascal or C, and types in XSD, the >> specification is completely mute.) The ebXML folks extended/interpreted >> that model to naming "types" as well. That was a stretch, and it just so >> happens they got it wrong when they made Representation _Term_ part >> of their >> model. >> >> So... since RepresentationTerm is... a "term"... and it is defined by ISO >> 11179 as part of the dictionary entry _name_ -- I don't see any >> justification for making it stand for "the set of semantic primitives". >> >> The argument gets stronger when we consider the practice right now in >> LCSC. >> They are using the RepresentationTerm only as a part of the >> dictionary entry >> name -- not really as a "type". In their current usage, that part of the >> dictionary entry name, names a _property_ whose type is either a CCT >> or an >> ABIE or a BBIE depending on which kind of property is being described. >> >> In current _practice_ there are three kinds of types in UBL: >> Aggregate Core >> Components (ACC's), Basic Core Components (BCC's) and Core Component >> Types >> (CCT's). Each of these needs a dictionary entry name. Also each of the >> properties of each instance of each of these needs a dictionary entry >> name. >> Each of those dictionary entry names will need a "Representation >> Term" if we >> are to apply ISO 11179. >> >> Please have a look at the attached diagram. In it I show the mapping >> of ISO >> 11179 naming to the proposed CC model. Notice that an ISO 11179 >> dictionary >> entry name always has ObjectClassTerm, PropertyTerm, and >> RepresentationTerm. >> A DataElementName (using ISO terminology here!) names a DataElement. >> From >> the standpoint of ISO 11179 there are two kinds of DataElement in Core >> Components: >> >> 1. a property of an Aggregate Core Component >> 2. a property of a Core Component Type (i.e. its Content Component or >> one of >> its Supplementary Components). >> >> These are the "data elements" that ISO 11179 allows us to name (with the >> tripartite naming scheme). >> >> My proposal provides a clean separation betwen the concepts that comprise >> the dictionary entry name from the concepts that comprise the CC model. >> This is appropriate since dictionary entry names must be applied to many >> different parts of the model. The names are separate from the things >> named. >> >> So an ACC, Contact can have a property called homeAddress of (ACC) type >> Address. We'd need three dictionary entry names to describe this >> situation: >> >> ObjectClassTerm PropertyTerm RepresentationTerm >> --------------- ------------ ------------------ >> Contact * this dictionary entry is >> for the >> Contact ACC >> Contact homeAddress Address * this dictionary entry is >> for the >> homeAddress property of Contact >> Address * this dictionary entry is >> for the >> Address ACC >> >> Now let's say Address has a property called street which is of (BCC) type >> Street which in turn is of (CCT) type StreetType (I hate the fact that we >> have both BCC's and CCT's but one battle at a time!!). We'd have >> something >> like: >> >> ObjectClassTerm PropertyTerm RepresentationTerm >> --------------- ------------ ------------------ >> Address street Street * this dictionary entry is >> for the >> street property of Address >> Street *content* Text * content >> Street *supp:x* ... * supplimentary goop... >> >> And we'd _infer_ the CCT type (StreetType) from the BCC type Street >> (that's >> unambiguous since a BCC has exactly one CCT -- that much is undisputed). >> >> The point of this exercise was to show that we've got two kinds of data >> element (per the ISO defintion), both of which will need dictionary entry >> names, and both of which will need an attribute describing their "kind". >> Applying ISO 11179, that attribute is called "RepresentationTerm". >> However, >> the thing named is not the term. In the first case, the thing named by >> RepresentationTerm is the Address (ACC) type. In the second case, >> the thing >> named by the RepresentationTerm is the Street (BCC) type. >> >> Regards, >> Bill >> >> -----Original Message----- >> From: Michael C. Rawlins [ mailto:mike@rawlinsecconsulting.com ] >> Sent: Thursday, April 25, 2002 10:20 AM >> To: Eve L. Maler >> Cc: ubl-ndrsc@lists.oasis-open.org >> Subject: Re: [ubl-ndrsc] Proposal 3 in our CCTS feedback >> >> >> This is an interesting proposition, and I agree with most of it except >> for the bit that says that "the definition of Representation Term be >> modified". My guess is that the ebTWG CC team would flatly reject this >> as worded on the basis that they are using RT as defined in ISO 11179. >> I don't have a better wording right off, but I think you want to convey >> the idea that there must be a fully specifed set of supplementary >> components that is associated with each type of RT. >> >> Mike >> >> Eve L. Maler wrote: >> >> > I took an action to suggest revised wording for Proposal 3 in our CTTS >> > feedback. How's this? >> > >> > "We suggest that the definition of Representation Term be modified to >> > encompass the function of both Representation Terms and Core Component >> > Types, and that the notion of Core Component Types be removed, e.g. >> ..." >> > >> > I think we will also need to come up with an actual list of what the >> > RTs would be (though perhaps this belongs in a separate Proposal 3a, >> > or perhaps it should be associated with Proposal 4). Please see my >> > recent message for my proposed list. We don't have to tackle the >> > "inheritance" aspect at this time -- we can avoid it just by providing >> > a flat list -- but if people familiar with the CCTS process think it >> > will be well received, we can try it. >> > >> > Thanks, >> > >> > Eve >> >> >> -- >> Michael C. Rawlins, Rawlins EC Consulting >> www.rawlinsecconsulting.com >> >> >> >> >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: < http://lists.oasis-open.org/ob/adm.pl > >> > >-- >regards >tim mcgrath >fremantle western australia 6160 >phone: +618 93352228 fax: +618 93352142 > > -- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC