Namespace URI Design and Dereferencing

Dear SCA Technical Committees

In response to Sanjay's request for
cross-TC consistency in Namespace URI Design & Dereferencing, please
find attached the document discussed and agreed by the Steering Committee.
It is now submitted back to each TC with a recommendation for adoption.

Graham J Barber,

OASIS OpenCSA Steering Committee Secretary & Vice-Chair,

Program Director, SOA Partnerships,

      

Phone:

Internal:                  
           245702,  External: +44 (0)1962
815702

Secretary (Carol):          245395,    
               +44 (0)1962 815395

Cellphone (Worldwide):              
                     +44
(0)7880 734005

Subject: Namespace URI Design and Dereferencing

From: "Patil, Sanjay" <>

To: <>

Date: Thu, 4 Oct 2007 11:37:54 -0700

Title: Namespace URI Design and Dereferencing

Dear Steering Committee,

Following are some issues along with my proposed
resolutions related to the namespace URI design and dereferencing that
seem to apply to multiple OpenCSA TCs. I request the Steering Committee
to deliberate upon these issues and recommend a set of resolutions for
consistent adoption by all the OpenCSA TCs.

Thanks,

Sanjay 

1>  What namespace URI format should
be used by the different Open CSA TCs?

  Proposal: http://docs.oasis-open.org/OpenCSA/[defGroupName]/[yyyymm],
the [defGroupName] stands for a group
of semantically related definitions (e.g. SCA-Common to stand for the definitions
commonly provided by the different OpenCSA TCs)  and [yyyymm] represents
the year-and-month when the namespace URI came into existence (via a Committee
Draft vote).

   Discussion:

   OASIS guideline for URI design [1] recommends that the http
scheme namespace URIs defined by the OASIS TCs to begin with: http://docs.oasis-open.org/[tcShortName]/,
where the [tcShortName] is the short name of the TC (e.g. SCA-Assembly,
SCA-Bindings, etc). When more than one TCs provide definitions for the
same namespace URI, there is a conflict as to which TC's short name should
be used in the shared namespace URI. By design, the different OpenCSA TCs
are going to produce artifacts that are closely related to each other,
and therefore the guideline of compartmentalizing namespaces based upon
TC names seems rather artificial and restrictive. This proposal  resolves
the possible conflict by using short name of the member section (i.e.OpenCSA)
instead of the short name of any TC in the URI design. 

    The [defGrouptName] part
of the URI can be used to compartmentalize namespaces based upon the semantic
grouping of definitions. The definitions pertaining to any given [defGroupName]
may be specified by more than one OpenCSA TCs.  For example, a namespace
URI of http://docs.oasis-open.org/OpenCSA/SCA-Common/[yyyymm]
may be defined by the SCA Assembly TC as well as the SCA Bindings TC, SCA
Policy TC, etc.

    This proposal should also
work for the case where an OpenCSA TC wants to design a namespace URI for
its exclusive use. In this case, the TC should ensure that the value of
the [defGroupName] is unique across all the OpenCSA TCs.

    We should consider the
design and change of namespace URI as a separate issue from the versioning
of the artifacts providing definitions for that namespace URI. Namespace
URI is typically changed only when some definitions belonging to that namespace
undergo backward incompatible changes. There are situations where the version
number of artifacts may change but the namespace URI may remain the same.
For example, a TC may decide to bump up the version number of a specification
(e.g. use 1.5 instead of 1.1) to reflect some newly added changes, however
if the changes are backward compatible then there is as no need to change
the namespace URI.

    This proposal does not
use the version number of artifacts providing definitions in the namespace
URI design, but instead uses year and month of when the namespace URI was
first adopted by the TC. If the namespace URI must undergo a change due
to introduction of some non-backward compatible changes in the future,
then the new namespace URI can reflect the year-and-month of its adoption
by the TC. For example, if the SCA Assembly TC votes on its first Committee
Draft in Nov 2007, the namespace URI for the assembly definitions would
look like - http://docs.oasis-open.org/OpenCSA/SCA-Common/200711.
Now, if the SCA Assembly TC later introduces some non-backward compatible
changes and votes on a Committee Draft (say in Feb 2009) including those
changes, then at that time a new namespace URI should be introduced which
would look like - http://docs.oasis-open.org/OpenCSA/SCA-Common/200902

2> Should a namespace URI defined by the
OpenCSA TCs be dereferenceable? If yes, what document should be returned
when the namespace URI is dereferenced?

   Proposal: Any namespace URI defined
by the Open CSA TCs should be dereferenceable, and a RDDL 2.0 document
describing the namespace should be retrieved upon dereferecing the namespace
URI. The RDDL 2.0 document at the namespace URI should include pointers
to the various artifacts providing definitions for the namespace along
with a brief introduction for each artifact, description of the namespace
change policy, etc. As an example, we could refer some of the RDDL based
namespace description documents created by the OASIS WS-RX TC [2]. 

    When definitions for a
namespace URI are provided by more than one OpenCSA TCs, it is recommended
that a single TC be identified as responsible for collecting references
to the relevant artifacts owned by other OpenCSA TCs and creating a single
information document for that namespace URI. Following the same example
as used before, the information document for the namespace URI http://docs.oasis-open.org/OpenCSA/SCA-Common/[yyyymm] 
should be owned by the SCA Assembly TC.

[1] http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV07.html#URI-Design

[2] http://docs.oasis-open.org/ws-rx/wsrm/200702

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU

Namespace-URI-Design-Versioning-v3s.doc