Title: Re: [sca-assembly] Namespace URI Design and Dereferencing
Duane,
Just to be clear - the proposals (A, B and C) are not
alternatives to each other, but each of them is aimed at addressing a
unique concern.
About your point below - I agree that the proposal B would
avoid a potential conflict between multiple OpenCSA TCs trying to use the
same URI for their TC specific namespaces.
-- Sanjay
From: Duane Nickull
[mailto:]
Sent: Monday, Oct 22, 2007 9:16
AM
To: Graham Barber; ;
; ;
; ;
Subject: Re: [sca-assembly] Namespace
URI Design and Dereferencing
FWIW – I prefer B as it is less likely to be in
conflict. There was such a potential issue with WS-RM and
WS-ReliableMessaging at one point.
/duane
On 10/22/07
3:24 AM, "Graham Barber" <>
wrote:
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 <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 <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 <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 <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
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. You may a link to this group and all your
TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
**********************************************************************
"Speaking
only for myself"
Blog - http://technoracle.blogspot.com
Community
Music - http://www.mix2r.com
My Band -
http://www.myspace.com/22ndcentury
Adobe
MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************
