OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]