[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: Namespace URI string implications
At 2006-06-09 22:18 -0400, I wrote: >At 2006-06-09 13:47 -0700, jon.bosak@sun.com wrote: >>The point of minor versioning is to allow updates to the schemas >>without requiring implementors of the previous major version to >>revise all their software. > >But I have a problem with the above ... I believe they *do* have to >revise all their validation processes and software if there are >additions to the document models and we haven't accommodated that in >our NDRs for the major version. I have a discussion of this in >Section 9.3 of my discussion paper. In light of Jon's post, I've rushed this morning to embellish on section 9 of my discussion paper with a working demonstration of how the software deployed by implementers of the previous major version (say 2.0) will choke on an instance of a minor version (say 2.1) unless we make a change to the NDR to introduce a wildcard last element child of all elements with element children. Please find the latest version (0.2) of the discussion paper here: http://www.oasis-open.org/committees/download.php/18660/gkholman-ubl-modeling-0.2.zip I understand this is a radical suggestion, but I've looked through the UBL archives and I haven't seen any actually demonstrate W3C XSD Schema functionality in this regard. If there are others who believe as Jon believes in his statement above that a deployment based on our January UBL 2.0 document models would be resilient to a UBL 2.1 minor version upgrade, then please review chapter 9 of my new document posted above and tell me where I am wrong in my understanding of XSD schema validation semantics and how the demonstration is incorrect. And please show me using Xerces (which I am relying on as the best publicly-available implementation of W3C XSD Schema where its behaviours are fairly-well accepted) how the demonstration can be changed to illustrate your points. I am worried that since I'm the only one trying to demonstrate working code with XSD that I'm going to miss something that is obvious to someone else. I don't want to steer the group wrong, but I also don't want us to paint ourselves into a corner with UBL 2.0. In section 9 I now also bring up that if we go this route it brings into question the modeling of the extension point, since the accommodation for minor versions simultaneously accommodates element-level extensibility for subsets. Subset definition becomes a lot simpler with subset-specific elements declared throughout UBL inside of any element that needs it, instead of grouping all subset constructs under the extension point and having to implement the referencing back to the UBL content from inside the extension. I hope this is considered helpful. . . . . . . . . . . . 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]