[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Re: [code lists] drafct of section to put in documentation - for comment
I agree with Ken's response completely. Using values and using implemented schemas that validate the values used in instances are different things altogether. And I can see why Ken is both concerned and determined to make the schemas interoperate properly with other main document schemas. From what I read, I don't think Ken is insisting on any manner of implementation but one that does not break the integrity of inter-schema implementation and validation. From that angle, the current code list schema implementation architecture appears to support the keeping of such integrity well. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ On Mon, 27 Oct 2003, G. Ken Holman wrote: >>Thanks Mark for continuing this dialogue to help me better understand what >>is expected in UBL. >> >>At 2003-10-27 08:04 -0500, CRAWFORD, Mark wrote: >>>Are you stating that we would never switch from UBL code lists to >>>externally generated code lists? >> >>"Never" is a blanket word, but looking at the namespace declarations it was >>my gut feel that "foreign" code lists could not (ever?) be plug-and-play. >> >>>NDR was pretty specific in stating that external code lists would be used >>>wherever available, and that any UBL generated code lists would only be >>>used as an interim measure. >> >>Did the specificity apply to "external code list *expressions*" or >>"external code list *values*"? I believe the distinction is critical. >> >>The stylesheet I developed for creating private-use UBL-compliant code list >>expressions from sets of foreign code list values provides plug-and-play >>integration through the operating system copy facility as described in my >>earlier note, not necessitating any editing of any UBL schema expressions >>thereby not jeopardizing the integrity of the schema documents. >> >>If, however, one anticipates plugging in foreign code list expressions into >>UBL by editing the import statement to bring in that expression verbatim >>(many expressions are or should be read-only since they are under the >>purview of other organizations), there would be (I think) a tremendous >>ripple effect. >> >>Let's consider the UN Currency Codes as an example: I think choosing to >>use the external code list expression would change the data type for the >>currency value to be in the >>namespace >>http://www.unece.org/etrades/unedocs/repository/codelists/xml/CurrencyCode.xsd >>which would then require a (manual?) edit to each of >>UBL-CoreComponentParameters.xsd and UBL-Reusable.xsd, UBL-Invoice.xsd, >>UBL-Order.xsd, UBL-OrderChange.xsd and UBL-OrderResponse.xsd. >> >>Unless I'm mistaken the opportunity for jeopardizing the integrity of the >>schemas is immense when needing to do as much hand-editing as described >>above ... and it would have to be done by all parties involved in the >>interchange of validated documents. >> >>However, my proposed methodology of (1) synthesizing >>UBL-namespace-conformant code list expressions from a combination of an >>already-conformant placebo expression plus the values extracted from a >>foreign code list expression, and (2) wholesale copy of the desired UBL >>code list expression in place of the in-use code list expression, will >>require zero edits to any UBL schema expressions. This would also insulate >>the suite of UBL schema fragments from externally triggered changes in >>foreign code list expressions that might be unexpected and out of sync >>between two parties using UBL: say the UN currency codes were changed by >>the UN and all of the schemas then pointing to the foreign expression were >>rendered un-validatable until a continuing set of manual adjustments were >>made by all parties involved. >> >>Perhaps this helps understand my own perspective and my own understanding >>of the influence of namespace URI strings utilized in the UBL >>environment. Unless I'm missing something important, sanitizing the values >>found in foreign code list expressions to be compatible UBL expressions >>will be critically important to a sustainable and maintainable deployment. >> >>I would welcome any clarification I need to see to better understand the >>issues as my advice has been based on the assumptions noted above. If I'm >>wrong I need to be corrected. >> >>Thanks again, Mark! >> >>.............. Ken >> >>-- >>Next public European delivery: 3-day XSLT/2-day XSL-FO 2004-01-?? >>Instructor-led on-site corporate, government & user group training >>for XSLT and XSL-FO world-wide: please contact us for the details >> >>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) >>ISBN 0-13-065196-6 Definitive XSLT and XPath >>ISBN 0-13-140374-5 Definitive XSL-FO >>ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath >>ISBN 1-894049-11-X Practical Formatting Using XSL-FO >>Member of the XML Guild of Practitioners: http://XMLGuild.info >>Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc >> >> >>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php. >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]