[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Draft 2.0 Schemas with Currency Codes edited to unions
At 2005-12-07 10:31 -0500, Burnsmarty@aol.com wrote: >This is not a problem. We verified that the use of union of token >and code list would not permit automatic validation in parser. >However, you can see that the parser does understand the code set >and note that in XMLSpy you can pick from the list of codes. > >By precluding the use of substitution groups in the UBL schemas, it >is not possible to constrain the acceptable values in the schemas. >However, use of union allows others to restrict from this definition >which was not possible otherwise. > >This is, therefore, what I think is the best compromise given other >NDR decisions. Does this mean there is no role for the code list value validation methodology I'm working on? If the schemas do not parse against an enumerated list, this approach you've implemented appears to require the schemas be modified by restriction in order to do the value validation. My understanding was that the schemas used for validation would not be touched (as in the files were sacrosanct). Can the restriction be done entirely from an outside "shell" schema expression that includes the UBL schema expression? Is this shell schema what trading partners would exchange as part of their agreement to the coded values they'll accept? I looked in your examples directory and I didn't see an example of how trading partners would restrict the UBL 2.0 schemas to, say, a selection of only three currency values. Can you include an example so that we can see what trading partners would write in order to restrict a document's use of currency coded values? I had anticipated that the changes you were coming up with would still validate the "largest set" of coded values, and that supplemental processes would be used to validate subsets agreed-upon by trading partners. The UBL schemas would be the first pass required to be passed and rejecting instances that would never be acceptable anywhere, and the second pass would accommodate trading partner agreements. If this isn't the case, then I should stop the supplemental process to do code list coded value validation so that there is only be one way to do it. And that is fine with me to stop this, as it hasn't been completely documented ... just let me know ... there really shouldn't be two ways to do this. Thanks, Marty! . . . . . . . . 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]