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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

Subject: RE: [ubl-ndrsc] Proposal 3 in our CCTS feedback

Title: RE: [ubl-ndrsc] Proposal 3 in our CCTS feedback


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.



-----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

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

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

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.


-----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.


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

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC