[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

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

    
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.

    
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.

    
Combine methods 1, 2 and 3 as appropriate for the 
    individual features grouped into the new version.

    
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