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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: [ebxml-msg] Adding versioning notes


I'm not sure where it fits in chapter 1, but would recommend adding words such as:
Possible future versions of the Message Service Specification (this document) may
  1. Increase the version number (recommended value of the version attribute) used in ebXML SOAP extension elements and change or clarify semantics without modifying the allowed syntax (schema).
  2. Define one or more schema for new ebXML SOAP extensions and use a new version number in those extensions or throughout an ebXML message including such new extensions.
  3. Define one or more schema for new elements to be used in the various ##wildcard "slots" in existing ebXML SOAP extensions and use a new version number throughout the affected extension or entire ebXML message.
  4. Combine methods 1, 2 and 3 as appropriate for the individual features grouped into the new version.
  5. Define a new schema for all ebXML SOAP extensions and indicate the large change through a change in the version number.
While all versioning approaches listed above include a new version number, compatibility with existing versions will not be immediately apparent.  Changed semantics, new ebXML SOAP extensions or additions to existing extensions may request processing an MSH does not support.  MSH implementations SHOULD take a conservative approach and refuse to process messages containing ebXML SOAP extensions with an unrecognized version attribute value.  Reporting this refusal with an errorCode of NotSupported and severity of Error is RECOMMENDED.
 
Note: In all cases, any new schema will have a separate namespace from that defined in this document.  When used for new or replacement ebXML SOAP extensions, such a new namespace MAY lead to a SOAP mustUnderstand Fault [SOAP] rather than the ebXML handling described above.
 
This particular version (defined primarily using approaches 1 and 5 above) is not compatible with version 1.0 of the specification and SHOULD be rejected by MSH implementations that support only version 1.0.
I think this includes all versioning approaches possible with our current schema.  It ignores a general lack of ##wildcard slots I'll touch on in my detailed comments.
 
The current document uses the word MAY in reference to future versions of the specification.  This seems misleading and touches only on possible features in such a new version, not how versioning might be accomplished.  I've tried to cover the how of versioning with the suggestion above.  I'll try to cover any misleading "MAY" in my detailed comments as well.
 
thoughts?
    doug
 


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


Powered by eList eXpress LLC