RE: [sca-j] Namespace URI Design and Dereferencing

From
Mary McRae <>
Date
2007-10-22T13:27:54+00:00
ID
Thread
RE: [sca-j] Namespace URI Design and Dereferencing
To TC Chairs:

 

  Please note that namespaces must be approved by the TC
Administrator – while the Steering Committee has agreed to the proposal, OASIS
has not yet made a final determination to approve or disapprove the proposal. See
footnote [1] in Sanjay’s proposal, below.

 

Regards,

 

Mary

 

-----------------------------------

Mary P McRae

Manager of TC Administration, OASIS

email:   

web: www.oasis-open.org

phone: 603.232.9090

 

 

 

From: Graham Barber
[mailto:] 

Sent: Monday, October 22, 2007 6:25 AM

To: ;
; ;
; ;


Subject: [sca-j] 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