On Jan 24, 2007, at 1:54 AM, ant elder wrote:
On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
> Jeremy Boynes wrote:
>> -1 on the single namespace as it couples together all the
>> extensions - we would need to create a new version of the
>> namespace every time any extension changed its XML
>
> I prefer a single Tuscany namespace. This is what the OSOA specs
> are doing as well with a single SCA namespace for everything. This
> helps simplfy the programming model as application developers only
> need to declare the single namespace at the top of an SCDL file
> instead of having to list different namespaces for all the
> bindings, implementation types, policies etc. that they use.
A good goal but how is it achievable in a way that does not require
us to rerelease the schema, the Java and C++ kernels, all extensions
and anything else that references the schema in coordination every
time any one of those makes a schema change? And how do we prevent
changes in one extension impacting users who don't use that
extension?
BTW the OSOA specs do not assume a single namespace and AIUI they
require extensions to be in different ones. There is even discussion
in the spec group about associating user-specific namespaces with all
SCDL definitions.
Could you point to where in the specs it talks about requiring
extensions to
use different namespaces?
The spec will not allow "non-spec SCA" extensions to pollute the SCA
namespace. For example, any vendor or Tuscany extensions that do not
correspond to an SCA specification are not supposed to use the SCA
namespace. This should apply to Tuscany as well for extensions not
part of the Tuscany project.
All the extension spec drafts that I can find are
using the single SCA namespace, are these drafts just out of date?
I prefer as few namespaces as possible for now as well as it makes
the SCDL
so much simpler. How about using the single Tuscany namespace for
now and
any extension can change to use some other namespace in the future if
required.
In general I prefer avoiding namespace proliferation but Jeremy
raises valid points. Do you have some ideas on how to address those?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
