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: [opencsa-liaison] Namespace for bindings and other extension points (was: Latest/This Version URI for Schema/WSDL files)


 
Hi Simon,
 
I guess the LSC's guideline was not fully reflecting the underlying assumptions. Here are the key points (in my own words, and as I understand):
 
- The final version of all the SCA specifications will be tagged with a common version number (the current assumption is - 1.1).
 
- Before all the TCs produce the final material (i.e. 1.1 version):
 a> We will use a common namespace that will be owned by the SCA Assembly TC (ownership here loosely means coordinating across the different SCA TCs when a new revision of the common namespace is to be created, etc).
 b> If an SCA TC needs to introduce a backward incompatible change to the definitions in the common namespace, that TC notifies (via LSC) the Assembly TC to rev up the common namespace.
 
- It is only after the 1.1 version that we will try out the idea of using fine grained namespaces for temporarily managing the TC specific backward incompatible changes before merging the changes into the next revision of the common namespace.
 
I hope the above clarifies the intentions behind the guidelines and answers the questions in your email below. LSC members, please feel free to chime in.
 
-- Sanjay


From: Simon Holdsworth [mailto:simon_holdsworth@uk.ibm.com]
Sent: Friday, Jun 06, 2008 11:39 AM
To: Patil, Sanjay
Cc: Anish Karmarkar; Michael Rowley; opencsa-liaison@lists.oasis-open.org; sca-bindings@lists.oasis-open.org
Subject: RE: [opencsa-liaison] Namespace for bindings and other extension points (was: Latest/This Version URI for Schema/WSDL files)


Sanjay,

[please note I don't think I have permission to post to the Liaison SC mailing list, so this message may not appear there]

Thanks for circulating this.  Unfortunately I find several parts of the statement ambiguous.

"and use the TC specific fine grained namespaces post 1.1"

Are the fine grained namespaces post 1.1 only used if the TC introduces incompatible changes?

Does the following statement only apply post 1.1?

"Whenever an incompatible change is to be made to the schema, a new revision of the common namespace should be generated"

Does "post 1.1" refers to some specific single point in time at which all TCs agree to have reached a 1.1 level?

Given that fine-grained namespaces can be used post 1.1, why is there a necessity to generate a new revision of the common namespace?  I was under the impression that the fine-grained namespace could be used and revved for some period of time, until an agreed point was reached where the updates would be folded back into a new revision of the common namespace.

So should that statement actually be:

Whenever an incompatible change is to be made within a TC specific namespace, a new revision of the TC-specific namespace should be generated.

When the TC wants to update the version of their schema in the common namespace and lose the TC-specific fine-grained namespace for a major revision, that falls under the "Whenever an SCA TC decides to make an incompatible change which affects the common namespace" part.

Given all the above, I'd like to suggest the following disambiguation:

For defining elements used in the SCDL file, all SCA TCs should start by using the common namespace.  At a specific point in time version 1.1 of the common namespace will be finalized.  After that time TCs may elect to use TC specific fine grained namespaces when any incompatible change is to be made to their schemas.  Following that, whenever an incompatible change is to be made within a TC specific namespace, a new revision of the TC specific namespace should be generated. Whenever an TC decides to make an incompatible change which affects the common namespace, including updating the TC's schemas in the common namespace and discarding one or more TC specific fine grained namespace, that TC is obliged to inform all of the other SCA TCs, via the OpenCSA Liaison Subcommittee - and that the Assembly TC is responsible for  coordinating the change where it affects multiple SCA TCs.

Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com



"Patil, Sanjay" <sanjay.patil@sap.com>

06/06/2008 10:10

To
"Michael Rowley" <mrowley@bea.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <opencsa-liaison@lists.oasis-open.org>
cc
<sca-bindings@lists.oasis-open.org>
Subject
RE: [opencsa-liaison] Namespace for bindings and other extension points (was: Latest/This Version URI for Schema/WSDL files)





 
On 6/2/08 conf-call [1], the OpenCSA Liaison Subcommittee resolved the
below issue with the following guideline:

For defining elements used in the SCDL file, all SCA TCs should use the
common namespace, and use the TC specific fine grained namespaces post
1.1. Whenever an incompatible change is to be made to the schema, a new
revision of the common namespace should be generated. Whenever an SCA TC
decides to make an incompatible change which affects the common
namespace, that TC is obliged to inform all of the other SCA TCs, via
the OpenCSA Liaison Subcommittee - and that the Assembly TC is
responsible for coordinating the change where it affects multiple SCA
TCs.

[1]
http://lists.oasis-open.org/archives/opencsa-liaison/200806/msg00000.htm
l

Thanks,
Sanjay
Co-Chair, OpenCSA Liaison Subcommittee

> -----Original Message-----
> From: Michael Rowley [mailto:mrowley@bea.com]
> Sent: Tuesday, Mar 25, 2008 22:35 PM
> To: Anish Karmarkar; opencsa-liaison@lists.oasis-open.org
> Subject: [opencsa-liaison] Namespace for bindings and other
> extension points (was: Latest/This Version URI for Schema/WSDL files)
>
>  
> Good point Anish.  I suspect that one of us was indeed
> supposed to bring
> this up (I don't recall who, if anyone, was identified).  So,
> how about
> me.
>
> Dear Liason Committee,
>
> The Bindings TC would like guidance on the namespace to use for the
> various <binding.xxx> elements that it is in charge of defining.
> Specifically, the question is whether the bindings should
> always use the
> same namespace as SCA assembly, or whether they should each use
> different namespaces.
>
> The Bindings TC debated this question for a while at its F2F,
> but agreed
> that the approach taken should follow a generally agreed approach that
> would also apply to all of the extensibility points in SCA assembly
> (such as implementation elements <implementation.xxx> and interface
> elements <interface.xxx>).  As such, we think this is an appropriate
> issue for the Liason group to tackle.
>
> Argument Kickstart:
>
> At the F2F, we discussed the pros and cons of a few approaches.
>
> Each binding gets its own namespace:
> - This approach allows each binding definition to evolve independently
> from other binding definitions and independent of SCA as a whole.
>
> Everything in one "SCA" namespace:
> - This approach gives the user of SCA a set of technologies that are
> known to work together.  If each binding/implementation/etc evolved
> independently, then the user would be hard pressed to figure out which
> collection of them actually worked together.
> - Having one namespace means that there are fewer prefixes to
> define at
> the top of the various SCDL files (this seemed to carry less
> weight than
> the previous point).
>
> Both:
> - Perhaps it is possible to define
> bindings/implementations/etc in their
> own namespace, but then also create a overarching namespace
> that brings
> together "blessed" versions of each candidate technology.  XML Schema
> may not have good ways of doing this (I don't know), but in the
> worst-case, the element definitions could be repeated in a different
> namespace.
>
> No decision was made, but it was my impression that the last of these
> approaches carried the greatest appeal, if the details could be worked
> out.
>
> Michael
>
>
>
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Tuesday, March 25, 2008 3:13 PM
> To: Michael Rowley
> Cc: Mike Edwards; opencsa-liaison@lists.oasis-open.org
> Subject: Re: [opencsa-liaison] Latest/This Version URI for Schema/WSDL
> files
>
> Michael,
>
> Since we are the liaison reps from binding, were we (or was
> I) supposed
> to do this?
>
> -Anish
> --
>
> Michael Rowley wrote:
> > +1
> >
> > I don't think a meeting is necessary for this one, but I
> believe that
> > the binding TC was looking for input from the Liason committee
> > regarding whether or not the bindings should be in the SCA
> namespace,
> > a binding specific namespace, or both.  I thought that someone from
> > Bindings was going to be formally asking the Liason committee to
> > provide a recommendation on that.
> >
> > Michael
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.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








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