RE: [ubl-psc] udt:Amount type - does it need qualifying in UBL 2.0 ??

["Sylvia Webb" <swebb@gefeg.com>]

I understand this in theory.  I don't know if it offers users the greatest
amount of flexibility. What happens when ISO updates the currency codelist
and UBL specifies an older version?  If we don't specify the version, it
becomes the option of trading partners which one to use. This also
eliminates the need to update UBL when ISO updates the list.  
 
The ATG2 uDT Amount Type does include Amount Currency. Code List Version.
Identifier (see attached file). What additional version information do we
need?
 
Regards,
Sylvia
________________________________

From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] 
Sent: Tuesday, September 06, 2005 6:36 PM
To: Stephen Green
Cc: ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] udt:Amount type - does it need qualifying in UBL 2.0
??


I think this comes under a broader issue.  I apologize to Stephen for
repeating some of his points but I think it needs putting into perspective.

The real question we have to ask is what specialized data types do we
want/need for UBL 2.0?

Under CCTS, we are allowed to derived our specialized data types from the
ATG2 unqualified data types [note the horrible difference in terminology].
But if we do so we must model them and create the appropriate schema file.

In UBL 1.0 we did this for the data types where we wanted to specify values
for their attributes.   Mainly this meant codes sets.

UBL_Amount is the only specialized data type in UBL 1.0 that is not a code.
Therefore it is the only one not likely to be made redundant by the code
list debate.

We created UBL_Amount so we could mandate the use of a specific version of
the ISO currency codes in any BBIE that was an amount.  If we use the ATG2
unqualified data type called 'Amount' then this specifices ISO codes for us.
What it does not do is specify the version of ISO being used.

So I would say we do need to keep UBL_Amount as a UBL specialization of the
ATG2 unqualified data type called Amount.  We specialize it by making the
value of the attribute AmountCurrencyCodeListVersionID to be always "0.3".

Now we need to decide how to implement this.

Stephen Green wrote:


		We discussed off list whether to have our
	own qualified version of the udt:Amount
	 
	Mmm.. I don't think it is less of a use of the
	ATG2 datatypes to add our own qualified 
	datatypes. Just to do so as an example to
	others might justify it but it would still be better,
	I think, to only do so if the ATG2 unqualified
	datatype Amount is insufficient. This was what
	we agreed was the case when in 1.0 we added
	the UBLAmount (admittedly though it wasn't
	an alternative to the ATG2 udt:Amount but to the
	CCTS conceptual unqualified Amount): we
	wanted to limit the codelist version to - was it
	0.3 or 3.0 I can't remember - and to fix the
	relevant attribute to that. Now, however, I'd say
	we should avoid fixing any version attribute as
	a rule since it precludes backwards compatibility
	later when in a minor version we wish to change
	to a newer version say.
	 
	My opinion is that we don't want to fix the
	version of the currency codelist used with a major
	version Amount (as it might have to change in
	minor versions) but to allow users to specify
	which they use (and therefore be able to change
	it without having to progress to another major
	version). So we ought not fix it. Then the question
	is: Is the ATG2 udt:Amount appropriate for this
	without specialization/qualification? 
	 
	All the best
	 
	Steve
	 
	

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E
-22FF8CA5641F&ttype=2&tid=10476

atg2_udt_amounttype.doc