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

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

Please remember that on UBL-Dev I am speaking for myself and my own 
views and not, necessarily, the views of other members of the UBL 
committee or the committee as a whole.  I'll let them share their own 
thoughts on this.

At 2009-05-18 16:14 -0400, Crawford, Mark wrote:
>This requirement is addressed through the namespace declaration for the
>currency code list.

Sorry, I fail to see how the namespaces help.  They are a schema 
mechanism used by UN/CEFACT to support enumerations that does not 
meet all the cited use cases.

Allow me to explain myself again so that you can teach me what I do 
not see regarding how behind-the-scenes mechanics with namespaces can 
address the use cases I related.

To restate the requirement, a UBL 2.1 system needs to support the 
following five use cases, where the first four need to succeed:

  [1]  <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount>
  [2]  <cbc:TaxAmount currencyID="TRY">17.50</cbc:TaxAmount>
  [3]  <cbc:TaxAmount currencyID="TRL"
          currencyCodeListVersionID="2001">17.50</cbc:TaxAmount>
  [4]  <cbc:TaxAmount currencyID="TRY"
          currencyCodeListVersionID="2009">17.50</cbc:TaxAmount>

... while at the same time this fifth invalid combination must be rejected:

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

At 2009-05-18 16:14 -0400, Crawford, Mark wrote:
>Each of the 7 code lists used by the UDT schema are
>updated with each release of the directory.

And how would this at all support the need for a UBL 2.1 system to 
support a UBL 2.0 instance?  The updated release of currency codes 
does not have "TRL" because the Turkish Lira is satisfied with 
"TRK".  Thus your suggestion loses the requirement for simultaneous 
and backward-compatible support of UBL 2.0 instances by UBL 2.1 systems.

All new constructs in UBL 2.1 are optional in order for a UBL 2.0 
instance to not violate any structural constraints.

If, as you suggest, UBL 2.1 uses yet another UN/CEFACT UDT schema 
with baked-in hardwired codes for the updated currency values, then 
an instance of UBL 2.0 from Turkey will not validate with UBL 2.1 
schemas.  Your cited approach would not address use cases [1] and 
[3], as these instances would be improperly rejected because the new 
UN/CEFACT schema won't have "TRL" as a valid enumerated value.

>As such, there is no requirement for the supplementary component.

The supplementary component is needed so that use cases [3], [4] and 
[5] can be successfully addressed.

For code lists where the semantics of codes change with different 
releases of the code list (as I cited before has happened in the 
past), a user can choose to explicitly indicate the semantics desired 
by citing the release of the code list through the supplementary 
component.  And the rejection is available should such a citation be invalid.

>So let me make sure I
>understand this - UBL had deliberately chosen to deviate from the
>UN/CEFACT code list approach, and as a result, must also deviate from
>the UN/CEFACT representation of supplementary components.  Is that
>correct?

Your words, not mine.  I sure don't agree with the bit about 
supplementary components.  We sure cannot meet our user requirements 
with the current UN/CEFACT code list approach.  We can if we take out 
the code list enumerations and we add in the UN/CEFACT standard 
supplementary components from the CCL08B_17FEB09.xls spreadsheet that 
are not in the current UDT schema.

Please forgive me for not being able to explain myself any clearer to 
illustrate the user requirements that would lead you to your misunderstanding.

I think citing the namespaces issue is disingenuous and can lead 
readers of the archive away from the true situation.  Namespaces in 
this context are only used in W3C mechanisms for grouping 
enumerations in different sets.  At no time do the code list 
namespaces get exposed in XML instances.  Thus someone creating an 
instance based on UN/CEFACT core components cannot cite XML 
namespaces as part of their solution.

I accept that users of UN/CEFACT schemas who are not interested in 
backward compatibility, not interested in longevity of schemas or 
instances, and interested only in closed systems that work with 
static schemas would probably be willing to accept the cost and time 
of reworking their investment in existing instances of old systems in 
order to work with new systems with new schemas.

I'm interested in creating a UBL 2.1 system that supports UBL 2.0 
instances.  I cannot see how "Each of the 7 code lists used by the 
UDT schema are updated with each release" would enable such a UBL 2.1 system.

Even if I chose to use a new namespace for a new enumeration set, and 
even if I chose to use W3C Schema mechanisms to create a union in the 
schema data type of the two enumerations, I would probably be able to 
cover use cases [1] and [2].  And then even if I could simultaneously 
add the supplementary components with a union of values associated 
with the code lists (not sure W3C Schema would let me do that), that 
would happen to cover use cases [3] and [4].  But because W3C Schema 
1.0 validation does not support co-occurrence constraints, I would 
not be able to cover use case [5].

Yes, I suspect with conditional data types in W3C Schema 1.1 this 
might be able to be done, but perhaps only with one supplemental 
component and not necessarily with a combination, and anyway we don't 
have W3C Schema 1.1 to work with.

I look forward to hearing opinions from others on this list.  If I am 
missing something or being misleading, it would help me to hear from 
others who can show me how to meet all of the stated use cases.

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