Re: [ubl-ndrsc]

[Mike Rawlins <mike@rawlinsecconsulting.com>]

Dropping back in again to comment on this, since I plan to be submitting
comments individually on the CC spec. I've a few comments in-line.

Mike

At Friday, 05 April 2002, "Gregory, Arofan" <arofan.gregory@commerceone.
com> wrote <snipped>:

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

I find a one to one relationship to be the most intuitive.

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

This is actually a very poor example.  Location "code", strictly 
speaking,
falls into the CC definition of an identifier and not a code.  It is
not an enumerated list in any practical sense.  Calling it a "code" 
would
be like calling the U.S. Social Security number a "code".

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

I find this extremely confusing.  I don't see how there can be more 
than a
many RT to one CCT relationship under the current definitions, or one
to one relationship under my preferred alternative, if the piece of
information in question is classified with the correct representation
term.  In fact, if we find a case where the CCT can't handle the 
semantics, that may be a strong indication that the wrong RT has
been assigned (as in your example of Location "code").

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

I agree with that idea.

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

All this argues is that to be fully described semantically, a monetary
amount must have the value of the amount, the currency, and precision.

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

How is a "price" different from any other monetary amount?  I find this
distinction a bit arbitrary and confusing.

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

Agreed.

Without commenting on your proposal in any further detail, the failing 
that I found in  a recent CC spec (not the most recent) was that 
RTs were used to specify semantics but they themselves were not fully 
specified.  I think the simplest and most straight forward solution 
is to insure that the CC spec fully describes the (compound) semantics 
of each Representation Term.  That is what I will suggest in my comments.
If that is done, it should be very straight-forward to develop 
a set of CCTs that reflects a one-to-one relationship between RTs 
and CCTs.  (Or, even better, do away with CCTs entirely!  However,
I don't expect that anyone is going to go for that radical a suggestion 
;^) )

Cheers,

Mike

---------------------------
Michael C. Rawlins
Rawlins EC Consulting
www.rawlinsecconsulting.com




===================================================================
EASY and FREE access to your email anywhere: http://Mailreader.com/
===================================================================