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: Minor Versioning Issues/Questions


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

       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?

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]