[ubl-ndrsc] Arofan's RT/CCT Draft Definitions

I agree with just about everything Arofan says here right down 
to the very end where he makes the point about the terms being backward (that RT 
and CCT should properly be reversed).  It was informative to finally hear 
such a lucid explanation of the history behind these two constructs.  If we 
could get this sorted out to the satisfaction of UBL and CC folks this would be 
a huge step forward.

The only thing I'm left wondering about is this: in 
light of Arofan's proposal do we really need what is now called RT's at 
all?

What's the alternative (to dropping RT's) -- do we leave RT's in the 
UBL model and do they get reified as XSD (complex) types?  And then do we 
go around extending those types with the CCT (complex) XSD types?  If 
that's the case then how will I reuse one of the CCT's between two RT's -- for 
instance the Text CCT is gonna be a really widely used structure -- across many 
RT's.  There isn't any multiple inheritance in XSD -- that's what you'd 
need in order to implement the many-to-many relationship between base and 
derived types suggested in Arofan's proposal.

An alternative is for the 
UBL _model_ to treat RT as an "adornment" or "stereotype" for documentation 
purposes but to elide it when it comes to the XSD model -- or to stick it in as 
a post-validation default attribute the way we're doing with uuid's.  I 
don't want to get deep into exactly how we do that.  I think we can work 
that out in a separate thread.

I propose we add a little clarification to 
the first leg of Arofan's proposal:

(1) Have a set of Representation 
terms in the UBL working model which function as 
"semantic
primitives," as originally intended by the CC group in ebXML. (The 
list may
need to be altered slightly to include some missing types, but will 
not
undergo wholesale expansion). This indicates what the business purpose 
of
the data is, in an abstract sense, wholly separate from how it will 
be
represented when syntax bound.  When the UBL working 
model is syntax bound
into XSD the RT information will be represented in a 
manner similar to uuid's.  
There will be no XSD types for RT's.  
There will be XSD types for CCT's.

-Bill

-----Original Message-----
From: 
Gregory, Arofan [mailto:]
Sent: 
Friday, April 05, 2002 2:14 PM
To: Maler, Eve; 

Subject: [ubl-ndrsc]

Eve/NDR 
Folks:

Sorry this is late, but here is a brief write-up and suggested 
approach for
resolving the RT/CCT 
issues.

Cheers,

Arofan

________________________________________________

Representation 
terms/Core Component Types:

UBL needs to clearly define the role of 
CCTs and RTs, since the Core
Components spec fails to do this. I want to go 
over the history of the
development of thes concepts, so that we can make 
sure that we produce a set
of definitions that are sufficient to the needs of 
UBL.

Originally, there were *NO* CCTs. All we had in the CC work was a 
set of
semantic "primitives" that were called RTs. The list in the spec has 
not
changed much since then. At one of the ebXML meetings it was realized 
that
although some of the RTs were single bits of data, others were actually 
data
composites. For each RT, one (and exactly one, in theory) CCT was 
indicated,
to suggest the semantics of the properties needed to fully express 
the use
of the RT.

As we start trying to use the spec set up in this 
way (UBL and others), we
have been realizing that there are some significant 
failings in this system.
One great example of this is a Location Code, a 
common bit of data that
cannot be described as a set of enumerated values - 
what we traditionally
and typically think of as a 'code list' - even though 
it's business function
is that of a code. 

Core Components did 
not account for this phenomenon. Because it functions as
a "code", it has a 
semantic primitive RT of "Code" - this means that it has
a "Code" CCT, which 
allows you to point to a code-list and 
supporting
properties.

Unfortunately, this doesn't work. For this type 
of a "code" you need a
different set of properties in your physical 
expression of the business
data. (In the case of location code, this is a 
pattern, not an enumeration -
a different type of simple datatype in XSD, for 
example.)

This is true not only of codes, but also of other kinds of 
data. We need to
specify *both* the semantic primitive of the model (the 
Representation Term,
traditionally) *and* the set of properties by which it 
is made manifest (the
CCT), and there is neither a one-to-one relationship 
between RTs and CCTs,
nor a many-to-one relationship between RTs and CCTs. It 
is, by the practical
dictates of business information, a many-to-many, unless 
we substantially
increase the range of our RTs and CCTs. We must either 
extend these lists
significantly, or we must allow them to be combinatorial. 
We canot know how
to clearly define CCts and RTs until we understand whether 
they are
combinatorial or not.

There is another requirement that 
highlights this need, and it is something
that has not been addressed so far 
in UBL, other than as a comment against
the draft order from the 
LCSC.

This is the absolute need for a solid description of the 
physical
representation of data, at a finer level of detail than is 
currently
possible.

Take, for example, the degree of precision of a 
price. This is a fundamental
kind of data-type issue, since the degree of 
precision in prices defines the
tolerances used in the calculations for 
essential business processes such as
Order/ASN/Invoice reconciliation (aka 
"book-keeping").

If we are to describe a "price" using the current 
system, here is what we
would know about it:

RT = "Amount" (which is 
always a monetary amount according to the CC
definitions)
CCT = 
"AmountType" (which gives us a number and a currency code)

The degree of 
precision of the price cannot be specified in the semantic
model, given these 
capabilities. All monetary amounts are the same. But in
reality, prices have 
a very different specificity than some other monetary
amounts. This means we 
cannot simply assume a single precision for all
monetary amounts, and make 
that part of our syntax-binding.

In other words, there is a need to 
capture in the model some distinction
between a price and another kind of 
monetary amount, since they have
different requirements in terms of how they 
are represented. Please note
that, in this example, precision is *not* 
syntax-specific. It is a critical
property of the business data itself, and 
can be described equally well in
many different 
syntaxes.

SUGGESTED APPROACH AND DEFINITIONS:

I would suggest 
the following approach to solving these difficulties:

(1) Have a set of 
Representation terms, which function as "semantic
primitives," as originally 
intended by the CC group in ebXML. (The list may
need to be altered slightly 
to include some missing types, but will not
undergo wholesale expansion). 
This indicates what the business purpose of
the data is, in an abstract 
sense, wholly separate from how it will be
represented when syntax 
bound.

(2) The list of CCTs should be expanded to reflect the actual 
needs of
expressing business data in a syntax, to cover those cases where the 
syntax
itself is not the determining factor, but rather the representation of 
the
business data (as is the case for numeric precision of prices). 
Alternately,
the CCTs could have properties added to them so that the range 
of possible
representation formats is one of the properties. This would work 
very neatly
for something like datetimes, for ecxample, but might become very 
confusing
and clunky in referring to numeric formats.

In either case, 
the range of expressive possibilities for CCTs should be
expanded.

(3) 
Each representation term could be combined with some specified subset of
the 
available CCTs, as determined by the requirements of reality. An
"Identifier" 
RT could be a CodeType, or it could be a TextType, biut we
would no longer 
have ambiguous types like "IdentifierType". The CCT would
now define an exact 
set of properties that would describe the actual
representation of the data, 
rather than describing its semantic or business
function. (This is 
essentially abstracting the idea of simpleTypes in XSD up
a level, but still 
referring to the actual physical representation of the
data, rather than its 
semantic.)  This would result in a significant
increase in the number of 
CCTs (or their expressive range) and would result
in the removal of some of 
the existing ones. The current list assumed a
many-to-one relationship 
between RTs and CCTs that is not useable in
reality. We need to re-work the 
list to reflect this finding.

NOTE:

The names "Representation 
Term" and "CCT" are not particularly good, so if
you want to reverse them, 
you could. I wanted to avoid confusion within CC,
however, by not redefining 
them as their exact opposites. Traditionally, the
RT was the semantic 
primitive, and the CCT was a construct that encapsulated
the property set for 
representing that 
primitive.

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