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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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


Subject: RE: [sca-bindings] Versioning, Namespace URI Design Discussion


ACK receipt.

Mary is unavailable at the moment, but I'll coordinate with her at earliest
opportunity.  I've thought about this only momentarily, but I don't
foresee any difficulty arrving at a workable solution that meets
all the desirable goals.

Best wishes,

Robin Cover

------------------------------------------------------------------

On Tue, 2 Oct 2007, Patil, Sanjay wrote:

>
> Hi Mary, Robin,
>
> I am planning to forward my note below to the Open CSA Steering
> Committee so that they can discuss it and possibly make a recommendation
> to all the Open CSA TCs. Before I do that, I wanted to check with you
> whether it would be ok with OASIS for multiple TCs to specify
> definitions for a single namespace URI. I am sure this idea leads to
> questions such as - which particular TC owns the namespace information
> document (e.g. RDDL 2.0 based) if the namespace is fleshed out by
> multiple TCs? I also think that we can arrive at some workable solution.
> But before we go there, I wanted to make sure that the OASIS staff is
> not going to rule out the possibility of sharing a namespace across
> multiple TCs. It will be great if we can resolve this issue via email
> before Friday (when the Steering Committee meets again).
>
> -- Sanjay
>
>
> ________________________________
>
> 	From: Mary McRae [mailto:marypmcrae@gmail.com] On Behalf Of Mary
> McRae
> 	Sent: Monday, Oct 01, 2007 5:25 AM
> 	To: Patil, Sanjay; sca-bindings@lists.oasis-open.org; 'Mike
> Edwards'; martin.chapman@oracle.com; 'Ashok Malhotra'; 'David Booz';
> 'Michael Rowley'; Blohm, Henning; 'Anish Karmarkar'; 'Bryan Aupperle'
> 	Cc: 'Robin Cover'
> 	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]
> 	Sent: Monday, October 01, 2007 2:18 AM
> 	To: sca-bindings@lists.oasis-open.org; Mike Edwards;
> martin.chapman@oracle.com; Ashok Malhotra; David Booz; Michael Rowley;
> Blohm, Henning; Anish Karmarkar; Bryan Aupperle
> 	Cc: Robin Cover
> 	Subject: [sca-bindings] Versioning, Namespace URI Design
> Discussion
>
>
>
>
>
> 	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?
> 	  I think 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 under the 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 the version number of specifications
> (e.g. use 1.5 instead of 1.1) merely to reflect the amount of new work
> that made into the new version, however the new version as such is still
> backward compatible with the previous version.
>
> 	  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
> <http://docs.oasis-open.org/%5btcShortName%5d/%5btcProductName%5d/%5byyy
> ymm> ], 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?
> 	  The OASIS guideline for URI design [2] recommends that the
> http scheme namespace URIs defined by 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 such as sca-assembly,
> sca-bindings, sca-j, etc. So when multiple Open CSA TCs plan to
> contribute to the same namespace URI, we have a conflict. Looking at the
> contributed material to the different Open CSA TCs,  it seems that we
> currently have this problem, for example, the namespace
> "http://www.osoa.org/xmlns/sca/1.0 <http://www.osoa.org/xmlns/sca/1.0> "
> is defined by the schema for SCA Assembly (contributed to SCA-Assembly
> TC), schema for SCA WS Binding, SCA JMS Binding (contributed to
> SCA-Bindings TC), etc. A solution here would be to use the short name of
> the member section (i.e.OpenCSA) instead of short name of he TCs, that
> is, the namespace URI shared by the different Open CSA TCs would begin
> with http://docs.oasis-open.org/opencsa/
> <http://docs.oasis-open.org/opencsa/>  However it would be advisable to
> consult the OASIS staff if we were to adopt such a solution since it is
> technically in violation of the OASIS guidelines.
>
> 	- 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,
> 	Sanjay
>
> 	[1]
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/metadata03.ht
> ml
> <http://docs.oasis-open.org/specGuidelines/namingGuidelines/metadata03.h
> tml>
> 	[2]
> http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamin
> gV07.html#URI-Design
> <http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNami
> ngV07.html#URI-Design>
> 	[3] http://docs.oasis-open.org/ws-rx/wsrm/200702
> <http://docs.oasis-open.org/ws-rx/wsrm/200702>
>
>


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