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
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
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