Re: [ubl] Minor Versioning Issues/Questions

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

I can answer some of these, as long as it is not taken as a symptom
of my ability to initiate a dialogue ;)


Grimley Michael J NPRI wrote:
> Greetings,
> 
>    In preparation for the discussion concerning a minor versioning strategy, we thought it best to make sure everyone is 'on the same page' and that we all agree on what the issues are.
> 
>    Originally, our minor versioning strategy was going to be derivation-based. That is, the new schema would import the previous version of the schema and use xsd:derivation (along with defining new types) and take advantage of 'polymorphic processing' and all that wonderful stuff. The minor-version schema would only contain the deltas and would capture its version number within its namespace name. I believe these decisions were made without any real consideration as to how these minor-version schemas would be generated from the model.
> 
>    After reviewing many of the emails concerning minor versioning, I've come up with this initial list of issues and/or questions (please feel free to add to this list):
> 
>        Question 1: Should minor-version schemas only contain the deltas, or should everything be redeclared (with the 'ccts:Version' documentation component reflecting the version of individual types).
> 
>        Question 1.a: Should we have minor-version spreadsheets that only capture the deltas and their relationship to the major version?
> 
>        Question 2: Should the namespace name change for minor versions? How about the namespace prefix?
> 
>        Question 3: What, specifically, determines whether a new version of the schema is actually a 'minor' or 'major' release? (If the schema only includes the deltas, and utilizes xsd:derivation concepts, the answer should be simpler than if the versioning is strictly model-based.)
> 

Backwards compatibility. IOW, if a change is introduced in a schema that makes
the schema backwards incompatible with the previous version, then the new
schema automatically triggers the condition known as "major version". Note
that this is not a function of the number of changes, but of the quality of
those changes.


>        Question 3.a: What does 'backwards compatible' mean to you? That any instance of the previous schema will validate to the new schema? That any instance of the new schema will validate to the old schema? (I've always thought it to be the first option, but have since come to realize that many people disagree.) Something more? Or less?
> 
People do confuse backwards and forwards compatible. So let's do a couple
of definitions:

a) compatibility -- a schema is said to be compatible with another
schema if instance documents validate equally against both schemas.

b) forwards compatibility -- a schema X is said to be forwards compatible
with a schema Y if documents that validate against schema X also validate
against schema Y, and schema X precedes (in time, or in version) schema Y.

c) backwards compatibility -- a schema X is said to be backwards compatible
with a schema Y if documents that validate against schema X also validate
against schema Y, and schema X follows (in time, or in version) schema Y.

In other words, if all documents that validate against MySchema v1.0
also validate against MySchema v1.1, then MySchema v1.1 is said to
be backwards compatible; but there is no expectation that any document
that validates against MySchema v1.1 must also by necessity validate
against MySchema v1.0

Example: MySchema v1.1 contains two optional elements, a and b; MySchema
v1.0 contains three optional elements a, b and c; a document that
validates against v1.1 will validate against 1.0; but a document that
validates against 1.0 and contains c will not validate against 1.1;
thus, 1.1 is backwards compatible, but 1.0 is not forwards compatible.

If 1.0 were forwards compatible, and 1.1 were backwards compatible,
you would have wasted a lot of time ;)


>        Question 4: Is (are?) Substitution Groups still on the table?
> 
> 
> Thanks,
> Mike 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Corporate Standards            |         Phone:  +1 510 550 4616 (internal x31442)
Sun Microsystems Inc.          |         W3C AC Rep / W3C AB / OASIS BoD