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] | [List Home]

Subject: Namespace and Versioning

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

Namespace described by Part 1: Core, up to Committee Specification 1:

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:

The specification document sets will be available under a heirarchy of

And links to the latest TC-approved version of the specification will
be maintained as URLs of the form

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/


<eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200703/";>
    <eb:MessageInfo> ... </eb:MessageInfo>

  <ebadv:NewFeature xmlns:ebadv="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/adv/200706/";>
    This new element's contents defined in version 200706 of Advanced
    Features specification.


Pete Wenzel <pete.wenzel@sun.com>
Join the Open ESB Community <http://open-esb.org/>

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