[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] Versioning, Namespace URI Design Discussion
Hi
Sanjay,
I’ll chime in and hopefully save some discussion. There is no way for
more than one TC to create any single artifact so I’m not sure what is
meant by “-
How to formulate a namespace URI, which is used and defined by multiple Open
CSA TCs?” Each resource must be associated with a specification, and each
specification must be associated with a single Technical Committee. Technical
Committees can refer to each other’s work by incorporating a reference,
but they cannot contribute to, or alter that work. Regards, Mary From: Patil, Sanjay
[mailto:sanjay.patil@sap.com] This email
is to fulfill an AI assigned to me during the last conf-call of the
SCA-Bindings TC. As I understand, the AI was to identify the various top level
issues concerning versioning of artifacts, namespace URI design, etc. Since
this topic is also of interest to the other Open CSA TCs, I have included the
chairs of those TCs on the recipient list of this note. Following is
what I think are the high level questions (along with my commentary) concerning
versioning, namespace URI design, etc, for the Open CSA TCs. - What
version number should be used to describe the artifacts (specifications,
schemas, WSDL files, etc.) produced by the different Open CSA TCs? I
believe the Open CSA Steering Committee recently resolved to make a technical
recommendation for all the Open CSA TCs to adopt the same version number. As I
understand, the plan is to use '1.1' as the version number as of now. As
per the OASIS guideline for Metadata and Versioning [1], the version number
represents a significant body of work carried by a TC often leading to an OASIS
standard, and therefore the version number typically would not undergo
changes during the TC's life time. The version number of artifacts should not
to be confused with the various stages of the artifact drafts produced by the
TC (e.g. working draft 01, working draft 02, committee draft 01, committee
draft 02, etc.), and the revisions of each stage of a draft (e.g.
committee draft 02 rev 1, committee draft 02 rev 2, etc.). Please see the OASIS
guideline for more details. - Should the
version number be part of any namespace URI formulated by the Open CSA TCs?
A
solution here is to not use the version number in design of the namespace URI,
but use some other metadata (such as year and month of when the backward
incompatible change to the definitions under the namespace URI is introduced) .
For example, the http scheme namespace URI defined by the version SCA Assembly
TC specifications could be - http://docs.oasis-open.org/[tcShortName]/[tcProductName]/[yyyymm], where yyyymm
stands for the year and month in which the TC voted on the first committee
draft of the artifacts. - How to
formulate a namespace URI, which is used and defined by multiple Open CSA TCs?
- Should the
namespace URI be dereferenceable? If yes, what document should be returned when
a namespace URI is dereferenced? I
think the namespace URI should be dereferenceable, and a RDDL 2.0 document
describing the namespace should reside at the namespace URI. The RDDL 2.0
document at the namespace URI can then 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. We can look at some of the RDDL based namespace description documents
created by the WS-RX TC [3]. - Should the
decisions adopted by a TC regarding versioning, namespace design also reflect
in its language specific definitions, if any, such as java package names?
May I suggest the right experts in this area (not me) to chime in here. I hope the
above set of questions and commentary is helpful in understanding the high
level issues and making the initial set of decisions regarding namespace
design, versioning of artifacts, etc. For the actual concrete
resolutions, we should reference the detailed OASIS guidelines, etc. Thanks,
[1] http://docs.oasis-open.org/specGuidelines/namingGuidelines/metadata03.html
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]