Re: [ubl] Draft 2.0 Schemas with Currency Codes edited to unions

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

At 2005-12-07 14:18 -0500, Burnsmarty@aol.com wrote:
>No worries!

Thanks!

>The UBL committee is supporting the validation method via Schematron 
>you are working on. I am trying to make sure that users of UBL 
>schemas (as you say trading partners) are free to 
>redefine/substitution group/ or schematron as their hearts or minds direct.

Okaaaaaaayyyyyyy......

>I understand the committee to be going down the path of providing 
>the schematron to users to illustrate how to validate using that 
>method. I don't know if the group has settled on what documents, 
>schemas, xml files, are to be normative to UBL and which will be informative.

Oh, if we follow through with what I've started, then we've decided 
to make it a Committee Specification so that it can be pointed to by 
others who wish to follow a similar approach, and pointed to by 
trading partners as how to engage such requirements in their 
agreements if they choose to.

So it isn't normative to the definition of UBL2 schemas, but it will 
be normative for those who choose to use it in conjunction with UBL1 
or UBL2 (or, I posit, any system supporting code lists however 
defined in whatever schema language).

>The examples I provided in the past showed how to extend or restrict 
>the schemas.

I didn't see in the examples subdirectory how the extensions or 
restrictions were accomplished.  Are such approaches done without 
touching the published UBL schemas?  I'd like to be reassured that 
the schemas are untouched, because they really are sacrosanct and 
could indeed be flagged as read-only in systems to ensure they are 
not overwritten.

Can you point to where you posted the earlier examples?  (sorry for 
the extra effort)

>This exercise for me was only to show that the underlying schema 
>didn't break anything in UBL2.

I think Tony brought to light a concern in my mind that removing 
enumeration validation is breaking something valuable that we 
had.  Though I'll let others determine that as the supplemental value 
validation works wether or not the schema value validation works ... 
I've just portrayed in my current draft that trading partners would 
use schema value validation to reject instances with nonsensical 
values before using Schematron to examine those meaningful values 
that are or are not permitted.

Indeed the concept of extending enumerated lists is supported by your 
method, which is something that my methodology wouldn't support if it 
relied on UBL schemas that enumerated values, but does it make sense 
for UBL to claim that an information item is (for example) an 
ISO-approved currency value and then allow users to use a value that 
isn't in the ISO list?

What would the interaction of this approach mean to CCTS conformance 
(and I'm speaking a bit out of my hat here because I'm not too clear 
on what that means myself)?  Here I'm thinking that the group agreed 
in Ottawa to use the ATG2 data type definitions of some code 
lists.  Fine, I'm assuming your methodology incorporates the use of 
those ATG2 definitions.  Does opening the back door to allow other 
values somehow violate commitment to use the data type?  A UBL 
instance extended to allow a non-ATG2 coded value in a code list, 
when then converted to some other representation based on CCTS and 
using the ATG2 code list, will not pass validation in that other 
representation because the value used isn't allowed.

So if we do allow this, can we still claim the code list conforms to ATG2?

>  Let me know if this email didn't clear things up for you.

It supported what you were saying earlier, but I'm unclear on the 
benefit of removing enumeration validation, I'm unclear on the impact 
of the decision to use ATG2 code lists, and I would like to see a 
working example of how trading partners would follow your proposed 
approach to agreeing on a subset of values so that I can better 
understand the mechanics involved.

Thanks again for your efforts with this!

. . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal