Re: [ubl-ndrsc] Representation Terms

["Stephen Green" <stephen_green@seventhproject.co.uk>]

In thinking more about my previous e-mail,

a) of course, with regard to the Amount,

we do already have BIEs for various currencies.

It makes we wonder whether there has been a

reluctance to rely on those sparse supplementary

component attributes for the CCT Amount

and use separately declared Code BIEs for currency which

do have all the necessary supplementary components 

(in the CCT Schema, if not, now, in the 

CC DT Schema).

If my guess is right then maybe we are better off without

the rest of the Supplementary Components in 

Amount in order to avoid there being two ways to specify a currency.

To do this wouldn't we need either for a restriction to

be applied in the CC DT Schema or in the UBL DT Schema?

*** Then we'd also need the reversal somehow of the 

dropping of the supplementary components from the 

CC DT (RT) Schema for Code or perhaps a way

to use the CCT Code or to restrict the CCT (not CC

 DT) Code differently in the UBL DT Schema (including 

the missing Supplementary Components) 

and use that ***

On that line (perhaps going too far - so close to final release)

couldn't the same logic be applied to Measure

and Quantity - to avoid the use of their CCT Supp Comps for

UOM without the codelist mechanism:

If the Code Supp Comps were fixed 

we could restrict Measure and Quantity to have

no code supplementary components

Then we could add (the messy part?)

Code-based BBIEs to the model to specify UOM

Unlike Amount/Currency we'd have to do this for

each and every Measure and Quantity (they could

all be different) - perhaps creating an appropriate ABIE with

Measure.Measure and UnitsOfMeasure.Code

 

If someone says that the codelist methodology will rule

out the need to specify codelists (not codes, obviously),

I'm not so sure that a legal document wiould be allowed

to have codelists which aren't specified in the document itself.

This might, I *guess*, apply particularly to both

currency and measure/quantity. Having Currency BBIEs is

one thing but I'd guess they'd have in most global cases (albeit

perhaps not including the USA

where I've heard it is acceptable, at least in some cases,

not to even speicfy the currency) to specify

both currency and codelist (even if it's ISO 4217).

 

 

Steve

 

----- Original Message -----

From: Stephen Green

To: UBL NDRSC

Cc: ubl-lcsc@lists.oasis-open.org

Sent: Tuesday, February 03, 2004 8:28 AM

Subject: [ubl-ndrsc] Representation Terms

I'm going through the CCT Datatype (Representation Term) Schema and I have a few issues still

outstanding really from the last instance sample

generation / review cycle

 

1.  In Measure and in Quantity we still have

unitCodeListID 

unitCodeListAgencyID

unitCodeListAgencyName
as supplementary components

 

but in Code we have this restricted to

*none*

 

and in Amount we have it defined in the CCT Schema as

currencyID

codeListVersionID

 

My question/issue is:

 

with Code:

the codelist mechanism might have to be very good to avoid

need for any meta data at all - can we guarantee this?

Shouldn't we still have

listID

listAgencyID

listAgencyName
?

 

with Amount a CCT issue really:

we seem to have a version ID

but is it decided and clear to all that there is

just the one codelist that can be used so that we don't even

have to specify what it is but only which version?

 

 

2.  Just a request for feedback from the last NDRSC

call (unavoidable that I couldn't make it) regarding

my issue of 

type="xsd:token"

missing from some of the elements in the Schema

 

3. Who will be editing the DT (CCT DT) and RT (UBL DT) Schemas?

Will it still be Gunther and Garrett?

Will it still be in collaboration / synchronisation with OAG and/or ATG?

How will it fit with the schedule? and tools work?

We'll presumably need any changes introduced prior to instance

generation. There may be some impact on this and on FPSC work

if the listID and listAgencyID are put back into the CCT DT Schema.

I don't see what can be done, if anything at this stage, about the

Amount supplementary components and how to specify the

codeListID

codeListAgencyID

and

codeListAgencyName

but if it were possible and agreed we'd need a suitable schedule for this

-

Otherwise perhaps something should be put into the Documentation

 

 

Sorry to keep pestering - just last minute rush

 

All the best

 

Many thanks

 

Steve