[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] RE: A discussion paper on UBL modeling issues and implementation
a) yes, makes sense that the author is responsible. In the current NDR 2.0 it is language construct that (partly) assures compatibility. b) I can see the proposed approach also being applied to CAC and CBC, which have elements, but not to QDT which has no elements. c) I'm a little surprised that there may not be any minor versions for the library modules. In the examples shown in the discussion paper, I see many BBIE's which I believe ought to be defined in CBC. Therefore, I assume that if a minor version of a document schema introduces a new BBIE, that it ought to be placed into a new minor version CBC. Or am I misunderstanding the approach? Regards Juerg ------------------------ Subject: Re: [ubl] RE: A discussion paper on UBL modeling issues and implementation approaches From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> To: ubl@lists.oasis-open.org Date: Mon, 12 Jun 2006 17:24:36 -0400 -------------------------------------------------------------------------------- At 2006-06-12 20:54 +0000, juerg.tschumperlin@minedu.govt.nz wrote: >Allow me to ask some questions to further my understanding of your >minor versioning proposal: > >a) It relies on the author of a minor version xsd file to correctly >retain the structure of the preceeding version, correct? Correct ... the new 2.1 constructs need to be in a different namespace, and the 2.0 constructs need to retain their old namespace, and in a given set of sibling elements the new 2.1 constructs need to follow the 2.0 constructs so as to fall into the "wildcard last child element of all elements with child elements" of systems implementing 2.0. >b) I can see how the proposal achieves forward and backward >compatibility in a document schema. Is it also applicable to library >modules CAC, CBC and QDT? Yes, I should think so ... I picture this for every element. I'm backing off a bit on the thoughts of putting subset extensions at the element level because of the contention between a subset extension and a minor version. I'm now thinking it is safer to keep extensions under the extension point and minor versions at the end of all elements. We then will avoid contention between an extension element and a 2.1 element that the extension definers want to use. But I'm still getting major headaches from W3C Schema in defining the extension point, as I'm unsure how to model the arbitrary order of *two* defined extensions and any number of undefined extensions under one extension point ... I think it will require two validation passes, one supporting the presence of each extension. Hopefully others will be able to assess the pros and cons of this approach. I'm going to add to my discussion paper with the creation of a mock subset schema and demonstrate the compatibility of the approach. This would give direction to organizations creating their own UBL subsets. This is one of the objectives of my hands-on training class I'm developing ... to instruct users in the creation and use of subsets of UBL. >Are we envisaging minor version library modules? "We"? :{)} The committee hasn't chosen to accept my proposal, and perhaps someone more expert than I will propose a more simpler solution to the problem. But I don't think so ... the schema expressions are exported from the models, and the new 2.1 constructs will be added to the models. This requires the models to maintain and preserve the namespace URI string for each construct added to the model (so that when the schemas are produced again the old namespace is preserved for old constructs and the new namespace is used for new constructs). And it would have to be decided if the "wildcard last child element of all elements with child elements" is something that we have to put into the model (which would be laborious to have it everywhere), or is something that the NDR merely state as a rule for the creation of a schema expression of all elements (thus guaranteeing it would be there for every element, thus making every element resilient to the addition of minor-version constructs). The resulting 2.1 minor version of UBL would be a schema expression where all elements have 2.0 child elements with 2.0 namespaces first, followed by 2.1 child elements with 2.1 namespaces next, followed by the wildcard to provide for 2.2 constructs. I hope this helps! . . . . . . . . . . . Ken -- Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 Also for XSL-FO/XSLT/XML training: Birmingham, UK 2006-07-04/13 Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04 Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06 World-wide corporate, govt. & user group UBL, XSL, & XML 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]