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] | [List Home]

Subject: Re: [ubl-ndrsc] Representation Terms

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).
----- Original Message -----
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
as supplementary components
but in Code we have this restricted to
and in Amount we have it defined in the CCT Schema as
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
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 
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
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

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