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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Re: [ubl] Minutes of Atlantic UBL TC call 13 May 2009


At 2009-05-15 19:59 -0400, Crawford, Mark wrote:
>As all supplementary components are already addressed, I would like 
>to see the specific stakeholder requirements that require attributes 
>vice the current approach.

As an example in the current approach you cite, the AmountType data 
type has been realized in the D08B UnqualifiedDataType_7p0.xsd schema 
fragment without a schema expression for the supplementary component 
"UDT000001-SC 3" named "Amount. Currency Code List Version. 
Identifier" found in row 9 of the CCL08B_17FEB09.xls spreadsheet.

Yildiray tells us that this year's ISO currency code list uses "TRY" 
for Turkish Lira, while in the currency list in play for UBL 2.0 
"TRL" is the code for Turkish Lira:

   http://lists.oasis-open.org/archives/ubl/200904/msg00015.html

So in UBL 2.1 we need to be able to support the following to be both 
backward compatible and current:

       <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount>
       <cbc:TaxAmount currencyID="TRY">17.50</cbc:TaxAmount>
       <cbc:TaxAmount currencyID="TRL"
          currencyCodeListVersionID="2001">17.50</cbc:TaxAmount>
       <cbc:TaxAmount currencyID="TRY"
          currencyCodeListVersionID="2009">17.50</cbc:TaxAmount>

While at the same time rejecting the following invalid combination:

       <cbc:TaxAmount currencyID="TRL"
          currencyCodeListVersionID="2009">17.50</cbc:TaxAmount>

And this cannot be done without the expressed attribute for the cited 
supplementary component for AmountType.  Note that the 
UnqualifiedDatTypeSchemaModule-2.0.xsd file that was chosen to be 
used in UBL 2.0 also does not have this modeled supplementary 
component expressed, so UBL 2.0 users are restricted only to say:

       <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount>

... and are not able to say:

       <cbc:TaxAmount currencyID="TRL"
          currencyCodeListVersionID="2001">17.50</cbc:TaxAmount>

Which is why we are making changes for UBL 2.1 both in schema 
validation (which, in order to support the four success use cases and 
one failure use case, cannot cite code lists in schemas) and in 
second-pass validation (which can support all five use-cases).

For items based on Code Type, this would be the equivalent to be both 
backward compatible and current:

   <cbc:DocumentCurrencyCode>TRL</cbc:DocumentCurrencyCode>
   <cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode>
   <cbc:DocumentCurrencyCode 
listVersionID="2001">TRL</cbc:DocumentCurrencyCode>
   <cbc:DocumentCurrencyCode 
listVersionID="2009">TRY</cbc:DocumentCurrencyCode>

While at the same time reject the following invalid combination:

   <cbc:DocumentCurrencyCode 
listVersionID="2001">TRY</cbc:DocumentCurrencyCode>

Note that the unqualified code type does have the required 
supplementary components for this use case.

This means that UBL 2.1 currency values must support two code lists, 
because "TRL" isn't in the new code list and "TRY" isn't in the old 
code list.  UBL 2.1 has to validate UBL 2.0 instances with "TRL" (to 
be backward compatible) and validate UBL 2.1 instances with "TRY" (to 
be current).

A simple W3C Schema union of values from two lists won't support the 
required rejections described above.  The proposed UBL 2.1 
second-pass validation does meet all the above use cases.

Having the supplementary component allows the user not to be 
ambiguous regarding in which list a specific code is found.  Without 
the supplementary component, one would not be able to distinguish the 
semantics of two codes of the same value from two different 
lists.  For example, the currency code "RON" for the Romanian leu has 
had two different semantic meanings in the life of ISO currency 
codes.  While not a problem between 2001 and 2009, it is an example 
of a real-world use case when established codes are reused for new purposes.

We have no idea if codes in code lists used by UBL will be reused in 
the future.  Users can choose to add instance-level meta data to 
coded values in order to be unambiguous and protect against future uses.

I responded to Yildiray with these details regarding how we cannot 
meet his specific stakeholder requirement with the current UBL 2.0 approach:

   http://lists.oasis-open.org/archives/ubl/200904/msg00016.html

Please let me know if you need any more detail regarding this 
established user requirement and how the current approach does not 
meet the need.

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

--
XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
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
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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