[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
Attachment:
Visio-Core Components Meta Model 4.pdf
Description: Binary data
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC