RE: Minor Versioning Issues/Questions (Updated)

[Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil>]

Greetings,

After review and discussion on last week's Atlantic call, we decided to add another (previously implied) question (see Question 5.) We have also included Eduardo's responses to questions 3 and 3.a.


    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.)

          <Eduardo>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.</Eduardo>

    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?

          <Eduardo>
          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.
          </Eduardo>

===========
    Question 4: Is (are?) Substitution Groups still on the table?

===========
    Question 5: What should be the normative version of UBL? Schema, Model or both.


==========================================================================

If we decide that minor-version schemas should only contain the deltas AND all changes should be initiated in the model then Bill Burcham has offered this possible solution:

"...perhaps we could have a separate spreadsheet for each minor revision.  It would be marked as a "minor revision" spreadsheet and the production process would produce appropriate schema from it.

All versioning/mods are done in the model in that they are done in Excel -- not in XML Schema. ... The Committee would also have to manually move forward revisions made in "minor revision spreadsheets" to the following "main spreadsheet".  The "minor revision spreadsheet" would have to explicitly or implicitly refer to the "main spreadsheet" and the generated "minor revision schema" would refer to a "major schema".

Another thing to like about this approach (using schema "sub-classing" for minor revisions) is that the same approach and tools apply to many end-user specializations of major or minor UBL releases.  In other words, the approach works for the UBL committee, and it can be reapplied to the output of the UBL committee -- by civilians, for their own fell purposes.

The rules for type substitution are widely understood in the programming community so folks don't have to learn a bunch of new concepts to know what to expect, or what's going to work."


Thank You,
Mike Grimley