Re: [ubl] Currency Codes - ISO 4217: TRY vs. TRL

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-04-13 10:38 +0000, Yildiray@srdc.com.tr wrote:
>Together with Revenue Administration of Turkey, we develop the UBL 
>2.0 based eInvoice schemas for Turkey. Details are available at the 
>following URLs:
>
>http://www.efatura.gov.tr
>http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-trlsc

Congratulations!

>The code for our currency "Turkish Lira"  changed at the beginning 
>of this year and it becomes "TRY". This change has been reflected to 
>ISO 4217 currency codes 
>(http://www.iso.org/iso/support/currency_codes_list-1.htm); however, 
>the UBL 2.0's "CodeList_CurrencyCode_ISO_7_04.xsd" document still 
>contains the old version of the code (i.e. "TRL").

That is a UN/CEFACT schema fragment incorporated by the UN/CEFACT 
schema fragment named in the UBL package as 
"UnqualifiedDataTypeSchemaModule-2.0.xsd".

>When does UBL community will reflect this change to the schemas? If 
>this change will not happen soon, for the time being, shall we 
>update the "CodeList_CurrencyCode_ISO_7_04.xsd" in our 
>implementation? (i.e. replace TRL with TRY).

You find yourself in a difficult position regarding a strict 
definition of UBL conformance.

In the soon to be published customization guidelines (a draft of 
which is found at 
http://lists.oasis-open.org/archives/ubl/200904/msg00010.html ... but 
some changes are being made so readers of the archive should look at 
the TC home page http://www.oasis-open.org/committees/ubl for the 
most up-to-date version of this document) the distinction is made 
between UBL conformance and code list conformance.

Using such a distinction, the UBL 2.0 release is regarded as having two facets:

   1) - UBL document structures and lexical constraints
   2) - a convenience code list collection that includes the currency
        list in play at the time UBL 2.0 was released

In the val/ subdirectory of UBL 2.0 there is an implementation of the 
convenience code list collection available for implementers who do 
not wish to create their own implementation of a different code list 
collection.  Using the work products of the OASIS code list 
representation subcommittee 
http://www.oasis-open.org/committees/codelist a community or even 
just a pair of trading partners can specify the code list constraints 
separately from the document structure constraints.

Therefore, I would think from your post it is your intent to conform to:

   1) - UBL document structures and lexical constraints
   2) - a code list collection that includes an updated currency
        code list

Fair enough, and entirely within the expectations of UBL users.  A 
community of UBL users should indicate to which set of structural and 
lexical constraints, and which set of code list constraints they 
conform to, so as to manage the expectations of trading partners.

And in the upcoming UBL 2.1 this distinction is clear cut.

Unfortunately, in the existing UBL 2.0, in only three places (one of 
which is currency codes), this distinction is blurred by the UBL 
committee adoption of the code list constraint mechanism used by 
UN/CEFACT for the unqualified data types.  The other two places are 
MIME type codes and units of measure.  The distinction is clear cut 
for every other code list in UBL 2.0, but not these three.

This blurring results from UN/CEFACT fixing the code list collection 
as the set of W3C Schema XSD enumerations you cite in 
CodeList_CurrencyCode_ISO_7_04.xsd.  The use in UBL 2.1 of the 
untouched UN/CEFACT XSD fragments means that UBL's code list 
specification techniques can only be used for restricting the three 
code lists with XSD enumerations.  UBL's code list specification 
techniques cannot be used for extending the three code lists with XSD 
enumerations.  UBL's code list specification techniques can be used 
for extending any other code list, and users can claim conformance to 
those extended code lists in conjunction with the UBL structures.

In UBL 2.1 you will easily be able to categorically state conformance to:

   1) - UBL 2.1 document structures and lexical constraints
   2) - a code list collection that includes TRY in the currency list

(no doubt that will be part of the UBL 2.1 default code list, but 
even if it were not, the principle is that you would be able to make 
the claim for any set of code lists with restricted or extended 
values for any code list and any additional code list)

In UBL 2.1 the val/ directory is proposed to contain a new 
UBL-defaultCodeList-2.1.xsl that supports the union of UBL 2.0 code 
lists and updated code lists in play at the time UBL 2.1 is 
released.  It is proposed that there will be no XSD enumerations in 
the UBL 2.1 schemas.  Code list conformance can then be separately 
claimed from document structure and lexical conformance.

So until UBL 2.1 is released I think that a strict reading of the 
specifications indicates you cannot formally be conformant to UBL 
because you cannot conform to the UBL 2.0 schemas because of the 
inclusion of the UN/CEFACT schemas.

You can, however, create a compatible document model.  When you 
modify CodeList_CurrencyCode_ISO_7_04.xsd you will need to create a 
new data type, and all UBL BBIEs that are based on the old currency 
type (directly or indirectly through the supplementary component) 
need to be new, which will create new ABIEs all the way up to a new 
document element.  This is accomplished simply by changing the schema 
fragment and then changing all the UBL namespaces to be custom 
namespaces and you will end up with a document structure compatible 
with UBL 2.0 but not conformant with UBL 2.0.

Then when UBL 2.1 is published, you'll be able to change the 
namespaces back to the standard UBL namespace and claim conformance 
to UBL 2.1 structures.  But your compatible instances that you create 
today will not be conformant to the UBL 2.1 structures published in 
the near future.

Note that the use of the UN/CEFACT XSD enumerations will be an 
Achilles heel for those users who extended the three cited code 
lists.  The proposed filtering of one of your extended instances with 
UBL 2.x constructs to an instance with only UBL 2.0 constructs will 
fail to validate with the UBL 2.0 schemas.  Thankfully the filtering 
of an extended instance with 2.y constructs to an instance with only 
UBL 2.x constructs will continue to work, so the problem will only 
exist with legacy implementations of UBL 2.0.  The problem will 
eventually clear as UBL 2.x implementations replace UBL 2.0 implementations.

But until then I think you are stuck with compatibility.  If you hack 
the enumeration list and continue to use the UBL 2.0 namespaces, you 
will work fine in a closed environment but for someone outside of 
your environment taking your use of UBL 2.0 namespaces at face value, 
they will not successfully work with your instances and their UBL 2.0 schemas.

The new use of OASIS genericode and context/value association is 
designed to address all of these issues, but it could not be fully 
implemented in UBL 2.0.  I cannot quickly find the minutes where it 
was decided within the UBL technical committee, but the committee has 
agreed not to have XSD enumerations for code lists in UBL 2.x.  The 
Schema Generation Task Group (SGTG) has already begun work in this 
area and will soon be making its interim work available to the UBL TC.

I hope this helps, Yildiray.  It is an important issue that UBL users 
need to be more aware of.  Please keep this in mind when reviewing 
the upcoming conformance documents and share your thoughts and concerns.

. . . . . . . . . . . . . . Ken

--
XSLT/XQuery/XSL-FO training in Los Angeles (New dates!) 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal