Re: [ubl-ndrsc] Bill&Eve's proposal on local/global elements

["Eve L. Maler" <eve.maler@sun.com>]

The proposal (which did get adopted; Mavis will be following up with the
minutes soon) does not depend on the RTs being identical to the CCTs.  It
seems to me that there is a crude implied inheritance mechanism at work
here, with the CCT Numeric.Type being an ancestor of several of the RTs!

Since the RTs are more expressive and since the TC committed to maintaining
a clear list of the RTs UBL uses (recognizing that we may need to add some due
to the syntax-specific nature of our work or for other reasons), it seems safe
to stick with RTs as part of our naming scheme.  The CCTs could end up being
referenced only in the dictionary documentation, and even then, if the CCTs
are less expressive, RTs work better there too.

I wonder, though, if it would be handy for us to explicitly keep track of the
RT-to-CCT correspondence even after we start adding a few new RTs.

         Eve

At 01:38 PM 1/26/02 -0600, Mike Rawlins wrote:
>One thing I do need to note, however, in case it did not come up in 
>discussion:
>
>There is *not* a one-to-one correspondence between CCTs and Representation 
>Terms
>in the latest CC technical spec.   For example, the representation terms 
>Percent,
>Rate, and Value all "link" to the CCT Numeric.Type.  Date Time.Type and 
>Text.Type
>also have such many-to-one links.  At first glance I'm not quite sure of the
>impact that this has on the proposed scheme, but I have a feeling that it 
>needs
>to be considered.   If the scheme is in any way dependent on a one-to-one link
>between types (XML schema type declarations and CCTs) and representation 
>terms,
>it is going to have problems.
>
>BTW - I think this many-to-one relationship between representation terms 
>and CCTs
>is, at best, an awkward feature of the current CC spec and will so state 
>during
>the public comment period.

--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com