[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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: mary.mcrae@oasis-open.org web: www.oasis-open.org phone: 603.232.9090 From: Graham Barber
[mailto:graham_barber@uk.ibm.com]
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, 1>
What namespace URI format should be used by the different Open CSA TCs?
Discussion:
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
Unless
stated otherwise above:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]