Upon further research and consultation with OASIS Staff (thanks Robin
& Mary), I've arrived at the following proposed modification to the
namespace and URI strategy, which now takes into account versioning,
and is intended to accommodate the TC's anticipated future
specification development efforts.
The concrete examples are the values I will use in the candidate PR 02
draft (WD 19), to be published shortly. Please respond if you have
objections or suggestions for improvement.
Namespace Change Policy
-----------------------
The normative specification of the schema and features identified by a
given namespace URI is subject to change, until approval as a
Committee Specification. At that time, no further changes which may
result in incompatibility with possible implementations will be made,
unless a new namespace is declared. (In practice, as you will see
below, such a revision is done by incrementing a date-derived element
of the URI.)
Namespace & Schema Versioning
-----------------------------
Robin pointed out the recent TAG draft at
http://www.w3.org/2001/tag/doc/versioning-xml-20070326.html
which discusses some of the options. Explicit version identification
attributes seem to be discouraged, as handling them "requires special
processing on top of XML and namespaces". Our Messaging/@version
attribute adds no useful information that is not already communicated
via the namespace declaration, so it could be removed. (version="3.0"
is not just a semantic variant of the previous header structure; it is
a completely new schema/namespace.)
I propose that we adopt approach #2, "all new components in new
namespace(s) for each compatible version". That is, the eb:Messaging
header will be described by the "core" schema and associated with a
namespace that is fixed by a given (CS) version of the spec & schema.
Extension elements (such as may be needed for features described in
Part 2 of the spec) will still "fit" into the core schema at the
various extension points, but will be declared in new namespace(s).
Examples
--------
Namespace described by Part 1: Core, up to Committee Specification 1:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/
If we determine that incompatible changes are required post-CS1, the
dated portion of the namespace will be incremented, and the entire
Core redefined thereunder, up to CS2.
e.g. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200705/
Feature names and constant identifier URIs defined in Part 1: Core;
formed by concatenating the namespace URI with a QName:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/defaultMPF
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/defaultFrom
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/defaultTo
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/service
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/test
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/oneWay
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/push
The specification document sets will be available under a heirarchy of
URLs:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/pr02/spec-name.pdf
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/cs01/schema-name.xsd
And links to the latest TC-approved version of the specification will
be maintained as URLs of the form
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/spec-name.pdf
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/spec-name.html
For Part 2: Advanced Features (or any number of separately specified
Advanced Feature Profiles), new namespace(s) will be created, in which
only the additional elements are defined.
e.g. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/adv/200706/
Example:
--Pete
Pete Wenzel