OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

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


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


it isn't boring to me because it focuses on the principles of what we are trying to do. that is, create specification for documents that establish unambiguous meaning for the information content.  giving a fixed set of possible values (eg. a list of codes) is a common practice for achieving this - but only if we can match the code to its true meaning.

the three options are:
1. no code list specified (entirely implementation specific)
2. code list but no version specified (partially determined by each implementation)
3. code list and version specified (determined entirely by the model).

in UBL 1.0 we tried for the third option.  but it is worth considering if that is too restrictive.

i tend to agree with you that...
The scenario I saw most frequently as an implementer was that
trading partners needed to use a new currency code long before ISO published
the updated list. 
- but doesn't this also apply to stating only a code set?  That is, if ISO have not yet issued an updated list with that code- then it isn't an ISO code and the code set limitation is restrictive as well.  In this case it isn't the version thats the problem, it is the code set.  Only when ISO issue the code (and our version doesn't have it)  does the versioning aspect come into play.

so my point was that if we don't do option 3. we may as well just do option 1.  thus removing any decision making for UBL and allowing implementors to do their own thing.  users can determine not only the version but the code list itself in advance.

the middle option (option 2.) seems like the worst of both worlds (partially restrictive but partially variable).  what advantage do you see in that?

Sylvia Webb wrote:
I apologize for this boring topic Tim and Stephen. I think it's important
for those who are new to the development process to understand the issues
here.

You are correct. UBL uses a constant of "0.3". I think it's important
however to determine if we need to be this restrictive at the data model
level. It is possible to specify code list versions at the schema level as
part of an implementation guide. At the data model level, I would expect to
see the code list called out (i.e. UNECE 6345), but, not necessarily the
version. The scenario I saw most frequently as an implementer was that
trading partners needed to use a new currency code long before ISO published
the updated list. If UBL specifies a code list version, the interoperability
problem that you mention is not solved.  

What I question is what appears to be an assumption that two companies will
exchange UBL business documents without agreeing to code list versions in
advance.  If this is the case, then it is very important to specify the code
list version. Everything that I'm reading and hearing seems to indicate that
the exchange of electronic business documents without specifying this level
of detail is a long term goal. Even with OASIS CPP and CPA standards, I'm
hearing that companies will continue to agree at a detailed level on
specifics like code list versions. There are always exceptions. Are these
exceptions part of the 80/20 rule?

Regards,
Sylvia  

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

you're correct the Identifier is available but in ATG2 it is left blank and
with UBL 1.0 we had a fixed value of "0.3".

it comes down to what we think these code lists are doing.  if we think they
are to give partners an ability to validate and understand the legitimate
values they will see in this BBIE then just specifying ISO currency code
(for example) is not enough. this is because they constantly change.  only
by adding the version do we fix the set of possible values.

otherwise, specifying a code list is simply giving a loose indication of the
types of values that may be found - but no guarantee of interoperability.

i agree we can leave this to the individual implementations to decide, but
then why not let them decide on code lists as well as versions? 
 there is not really much difference.

its rather like the ongoing problems with the rule that all terms must be in
the Oxford English Dictionary.  As we know the OED varies across editions
and versions, so we have to very specific if we want to be sure everyone is
using the same source - both for dictionary terms and for code list values.


Sylvia Webb wrote:

  
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






  

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



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