[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]