OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

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

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

Hi Mary:
At the SCA Policy TC call today the TC agreed to accept the proposal in 
Whether we need a specialized NS with the word POLICY in it, is still 
open to further discussion. Please let us know if this is acceptable to 

On Proposal C, we agreed to set up a RDDL document at the namespace. The 
format of the RDDL document shd be standardized across the SCA TC


Mary McRae wrote:

> 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: mary.mcrae@oasis-open.org <mailto:mary.mcrae@oasis-open.org>
> web: www.oasis-open.org <http://www.oasis-open.org>
> phone: 603.232.9090
> *From:* Graham Barber [mailto:graham_barber@uk.ibm.com]
> *Sent:* Monday, October 22, 2007 6:25 AM
> *To:* sca-assembly@lists.oasis-open.org; 
> sca-bindings@lists.oasis-open.org; sca-policy@lists.oasis-open.org; 
> sca-bpel@lists.oasis-open.org; sca-j@lists.oasis-open.org; 
> sca-c-cpp@lists.oasis-open.org
> *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,
> Graham_Barber@uk.ibm.com
> 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" <sanjay.patil@sap.com>*
>     * /To/: <opencsa-ms@lists.oasis-open.org>
>     * /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 
> <http://docs.oasis-open.org/OpenCSA/%5BdefGroupName%5D/%5Byyyymm>], 
> 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]/ 
> <http://docs.oasis-open.org/%5BtcShortName%5D/>, 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 
> <http://docs.oasis-open.org/OpenCSA/SCA-Common/%5Byyyymm>] 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 
> <http://docs.oasis-open.org/OpenCSA/SCA-Common/%5Byyyymm>] should be 
> owned by the SCA Assembly TC.
> [1] 
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV07.html#URI-Design 
> <http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV07.html>
> [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/

All the best, Ashok

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