sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [sca-assembly] Re: [sca-policy] Namespace URI Design and Dereferencing
- From: Graham Barber <graham_barber@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org, sca-bindings@lists.oasis-open.org, sca-bpel@lists.oasis-open.org, sca-c-cpp@lists.oasis-open.org, sca-j@lists.oasis-open.org, sca-policy@lists.oasis-open.org
- Date: Tue, 23 Oct 2007 09:36:38 +0100
Dave, all,
To be absolutely clear, the Document
represents the outcome of the Steering Committee discussion.
The original e-mail from Sanjay (dated
Oct 4th) represents the issue as raised to the Steering Committee.
I left it on to provide context but,
in retrospect, I probably should have snipped it.
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
----- Forwarded by Graham
Barber/UK/IBM on 23/10/2007 09:32 -----
David Booz <booz@us.ibm.com>
22/10/2007 15:20
|
To
| sca-assembly@lists.oasis-open.org, sca-bindings@lists.oasis-open.org,
sca-bpel@lists.oasis-open.org, sca-c-cpp@lists.oasis-open.org, sca-j@lists.oasis-open.org,
sca-policy@lists.oasis-open.org
|
cc
|
|
Subject
| [sca-assembly] Re: [sca-policy] Namespace
URI Design and Dereferencing |
|
I'm confused. The attached document has a different
proposal from this
email. Which is the recommendation, the email? I'll note that
the
attached document represents what I think most of the TC chairs support.
thanks
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Graham Barber
<graham_barber@uk
.ibm.com>
To
sca-assembly@lists.oasis-open.org,
10/22/2007 06:24
sca-bindings@lists.oasis-open.org,
AM
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
cc
Subject
[sca-policy]
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],
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
(See attached file: Namespace-URI-Design-Versioning-v3s.doc)
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]