MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Re: Namespace URI string implications
From: "G. Ken Holman" <>
To:
Date: Sat, 10 Jun 2006 10:40:42 -0400
At 2006-06-09 22:18 -0400, I wrote:
>At 2006-06-09 13:47 -0700, 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:
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
