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
|