You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "ant elder (JIRA)" <tu...@ws.apache.org> on 2007/01/23 13:35:49 UTC
[jira] Assigned: (TUSCANY-1053) Use a Tuscany namespace for all
non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder reassigned TUSCANY-1053:
----------------------------------
Assignee: ant elder
> Use a Tuscany namespace for all non-spec'd Tuscany extensions
> -------------------------------------------------------------
>
> Key: TUSCANY-1053
> URL: https://issues.apache.org/jira/browse/TUSCANY-1053
> Project: Tuscany
> Issue Type: Improvement
> Affects Versions: Java-M2
> Reporter: ant elder
> Assigned To: ant elder
> Fix For: Java-SCA-M3
>
>
> Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
There is a good article describing the issue here:
http://www.xml.com/pub/a/2003/12/03/versioning.html
Key points are 8 and 9: 8 says that is you have a strictly compatible
schema change you may be able to reuse an existing namespace (and
should if you can), whereas 9 says that in the face of an
incompatible change then you must use a new namespace.
Compatible changes are enabled through the use of extension elements
and allowing nodes that are unable to process them to ignore them
(including a mustUnderstand mechanism to control this behaviour).
This means that documents may be interpreted differently on different
platforms which is generally a good thing to allow but is bad in our
case as we need consistency across an SCA domain.
An additional concern that impacts us is that the SCA assembly is a
single construct derived from multiple XML documents rather than a
bunch of independent documents. We need consistent definition across
the documents used to define the assembly which means that liberal
parsing of different documents will cause problems.
On Jan 29, 2007, at 7:39 PM, Jean-Sebastien Delfino wrote:
> Comments inline.
>
> Jeremy Boynes wrote:
>> There are two concrete issues.
>>
>> Firstly, with the XSD for the namespace spread over so many files,
>> how does a user set up a tool to validate an XML document? They
>> can add schemaLocation elements as hints but that is more complex
>> than the separate namespaces. We can produce a single document
>> that includes the others but that couples them together and
>> requires us to version them all together.
>>
>
> This is usually specific to the tool. For example with the Eclipse
> XML tools you register your XSD in the Eclipse XML catalog. To
> validate SCDL composites using a set of SCDL extensions, you could
> just give your tool an XSD file including the XSD of the particular
> extensions. The user could write this XSD himself, or we could
> provide a very simple tool or maybe even just a script producing
> the XSD for him from the selected extensions for example. The
> single namespace approach is definitely simpler for users than
> having them declare so many namespaces, prefixes and
> schemaLocations in all their .composite and .componentType files.
You keep describing mechanics without any of the consequences. The
consequence of this is to combine all schema fragments from separate
files into one schema document. This process has constraints,
specifically that all these fragments are compatible with each other.
This requires coordination between all fragment authors to ensure
this consistency coupling their development together.
It does not matter if the user combines these themselves or if the
runtime combines them automatically as described in the previous
proposal, combination is still occurring.
The single namespace goal is a noble ideal but we have to deal with
reality and in reality versioning XML namespaces has well documented
issues. I laud the ideal but before we combine all our XML into one
namespace and couple all the extensions together I would like to see
a solution proposed for these issues.
>
>> Secondly, suppose we release kernel and ruby extension using V1.0
>> of a namespace. We then release V1.1 of the kernel which makes
>> schema changes so we need a new version of its schema, say 1.1;
>> this requires a new V1.1 namespace. How does a user validate the
>> V1.1 kernel XML with V1.0 XML for the ruby extension? The same
>> issue applies as new versions of the ruby or any other extension
>> are produced.
>
> I'm lost, sorry. It would help to go through a real concrete
> example. The Ruby XSD defines a RubyImplementation complex type
> extending the OSOA SCA base Implementation complex type, and an
> implementation.ruby global element with substitutionGroup = "the
> OSOA SCA implementationGroup" . It has no dependencies on another
> Tuscany kernel XSD. I'm actually not sure what you mean by "kernel
> XML". As far as I know there is no "kernel XSD" and I don't see how
> some "kernel XML" would reference a Ruby component. Can you help me
> understand with a real example? Thanks.
Simplified schemas:
kernel.xsd:
<schema targetNamespace="http://tuscany/V1.0">
... some definitions
</schema>
ruby.xsd:
<schema targetNamespace="http://tuscany/V1.0">
<element name="implementation.ruby>
<attribute name="file" type="xs:string"/>
</element>
</schema>
We make a change to the kernel and add/remove/update some definitions
and publish this as 1.1:
kernel11.xsd:
<schema targetNamespace="http://tuscany/V1.1">
... some definitions
</schema>
No change is made to the Ruby extension so it is still using 1.0 -
how does the user use the implementation.ruby element in a document
where the referenced namespace is http://tuscany/V1.1 without
specifying the 1.0 namespace for it?
>>
>> The scheme you describe allows users to reuse the same namespace
>> because it does not change the namespace when parts of the schema
>> are released. This means there are multiple definitions of the
>> same localPart in that namespace which is well known as being a
>> real issue.
>>
>> This is generally understood enough that there was a explicit
>> decision at the Assembly f2f last week (which we both attended) to
>> discourage this redefinition in SCA schemas due to the problems it
>> causes. Heck, we probably spent half the meeting discussing
>> mechanisms to cope with poor schemas that already suffer from this
>> problem - we do not need to make Tuscany's some of those.
>>
>
> We spent a lot of time discussing the usage of namespaces in SCA
> applications but we did not change at all to use different
> namespaces for the different SCA specifications. Maybe you are
> confusing the SCA SCDL schema and user schemas used in an SCA
> application? As far as I know, binding and component
> implementation type extensions (implementation.java, binding.ws,
> binding.jms, etc) are still in a single namespace, still using a
> '.' notation to build unique names in that single namespace. I
> think that this is an important characteristic of the SCA model, we
> are trying to avoid an unnecessary proliferation of namespaces. I
> want to keep the same approach in Tuscany: keep the programming
> model simple.
No, I'm not confused - we spent the meeting "discussing mechanisms to
cope with poor schemas that already suffer from this problem [of type
redefinition caused by poor versioning]." I'm all in favour of
avoiding unnecessary proliferation of namespaces but I am also aware
that in reality some proliferation is necessary. If we are to
encourage development and release of extensions (which benefits users
as they get more functionality) then an appropriate use of namespaces
is necessary.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Jeremy Boynes wrote:
> There are two concrete issues.
>
> Firstly, with the XSD for the namespace spread over so many files, how
> does a user set up a tool to validate an XML document? They can add
> schemaLocation elements as hints but that is more complex than the
> separate namespaces. We can produce a single document that includes
> the others but that couples them together and requires us to version
> them all together.
>
This is usually specific to the tool. For example with the Eclipse XML
tools you register your XSD in the Eclipse XML catalog. To validate SCDL
composites using a set of SCDL extensions, you could just give your tool
an XSD file including the XSD of the particular extensions. The user
could write this XSD himself, or we could provide a very simple tool or
maybe even just a script producing the XSD for him from the selected
extensions for example. The single namespace approach is definitely
simpler for users than having them declare so many namespaces, prefixes
and schemaLocations in all their .composite and .componentType files.
> Secondly, suppose we release kernel and ruby extension using V1.0 of a
> namespace. We then release V1.1 of the kernel which makes schema
> changes so we need a new version of its schema, say 1.1; this requires
> a new V1.1 namespace. How does a user validate the V1.1 kernel XML
> with V1.0 XML for the ruby extension? The same issue applies as new
> versions of the ruby or any other extension are produced.
I'm lost, sorry. It would help to go through a real concrete example.
The Ruby XSD defines a RubyImplementation complex type extending the
OSOA SCA base Implementation complex type, and an implementation.ruby
global element with substitutionGroup = "the OSOA SCA
implementationGroup" . It has no dependencies on another Tuscany kernel
XSD. I'm actually not sure what you mean by "kernel XML". As far as I
know there is no "kernel XSD" and I don't see how some "kernel XML"
would reference a Ruby component. Can you help me understand with a real
example? Thanks.
>
> The scheme you describe allows users to reuse the same namespace
> because it does not change the namespace when parts of the schema are
> released. This means there are multiple definitions of the same
> localPart in that namespace which is well known as being a real issue.
>
> This is generally understood enough that there was a explicit decision
> at the Assembly f2f last week (which we both attended) to discourage
> this redefinition in SCA schemas due to the problems it causes. Heck,
> we probably spent half the meeting discussing mechanisms to cope with
> poor schemas that already suffer from this problem - we do not need to
> make Tuscany's some of those.
>
We spent a lot of time discussing the usage of namespaces in SCA
applications but we did not change at all to use different namespaces
for the different SCA specifications. Maybe you are confusing the SCA
SCDL schema and user schemas used in an SCA application? As far as I
know, binding and component implementation type extensions
(implementation.java, binding.ws, binding.jms, etc) are still in a
single namespace, still using a '.' notation to build unique names in
that single namespace. I think that this is an important characteristic
of the SCA model, we are trying to avoid an unnecessary proliferation of
namespaces. I want to keep the same approach in Tuscany: keep the
programming model simple.
> You state below that coordination is required for multiple namespaces
> but that simply isn't correct when versioning is done as the
> references between them are to specific versions. Supporting that is
> more work for us as implementors as we need to support the multiple
> versions, but that is our problem and not users'.
>
> --
> Jeremy
>
> On Jan 25, 2007, at 5:50 PM, Jean-Sebastien Delfino wrote:
>
>> Jeremy Boynes wrote:
>>> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>>>
>>>> The C++ runtime allows bindings and component implementation types
>>>> to share a common Tuscany namespace and updates to them do not
>>>> require an update of the Kernel. We simply load the SCDL XSD files
>>>> out of each runtime extension directory and they can contribute to
>>>> a common namespace.
>>>>
>>>> As far as I know the Java runtime does not load or make any use of
>>>> the SCDL XSDs at this point, so I don't understand what the issues
>>>> would be with the Java runtime.
>>>>
>>>> The bindings and component implementation types defined by the OSOA
>>>> specs are in a single OSOA namespace. I think that the bindings and
>>>> component implementation types introduced by the Tuscany project
>>>> should be in a single Tuscany namespace.
>>>>
>>>> Extensions provided by other projects can be in other namespaces
>>>> obviously.
>>>
>>> How does this scheme address the versioning issues associated with
>>> XML namespaces?
>>
>> Could you explain what you mean by this?
>>
>>>
>>> The spec addresses them by coordinating releases from all binding
>>> and implementation groups.
>>
>> Is that right? I am not aware that all specs sharing the OSOA
>> namespace are going to be released at the same time. I understand
>> that the SCA core namespace needs to be released before the
>> extensions, but I can imagine different extensions being released
>> independently. If there are dependencies between the various XSDs
>> (for example a complex type extending another one) their updates
>> obviously need to coordinated but this would be true with multiple
>> namespaces as well.
>>
>>> Doing the same in Tuscany would take us back to a model where we
>>> need to coordinate kernel and all extension releases which is
>>> something we have decided not to do (for very good reasons).
>>
>> Like I said before I don't think that we need to update the kernel
>> when extensions change. The Tuscany C++ runtime for example picks up
>> extension XSDs from extension directories independent of the kernel,
>> and is able to pick up newer versions of these XSDs without any
>> change in the kernel. The Java runtime could do the same, but again
>> at the moment it does not load or make any use of the XSDs anyway...
>>
>> I still don't see any concrete issue at this point.
>>
>>>
>>> --Jeremy
>>>
>>>
>> --Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
There are two concrete issues.
Firstly, with the XSD for the namespace spread over so many files,
how does a user set up a tool to validate an XML document? They can
add schemaLocation elements as hints but that is more complex than
the separate namespaces. We can produce a single document that
includes the others but that couples them together and requires us to
version them all together.
Secondly, suppose we release kernel and ruby extension using V1.0 of
a namespace. We then release V1.1 of the kernel which makes schema
changes so we need a new version of its schema, say 1.1; this
requires a new V1.1 namespace. How does a user validate the V1.1
kernel XML with V1.0 XML for the ruby extension? The same issue
applies as new versions of the ruby or any other extension are produced.
The scheme you describe allows users to reuse the same namespace
because it does not change the namespace when parts of the schema are
released. This means there are multiple definitions of the same
localPart in that namespace which is well known as being a real issue.
This is generally understood enough that there was a explicit
decision at the Assembly f2f last week (which we both attended) to
discourage this redefinition in SCA schemas due to the problems it
causes. Heck, we probably spent half the meeting discussing
mechanisms to cope with poor schemas that already suffer from this
problem - we do not need to make Tuscany's some of those.
You state below that coordination is required for multiple namespaces
but that simply isn't correct when versioning is done as the
references between them are to specific versions. Supporting that is
more work for us as implementors as we need to support the multiple
versions, but that is our problem and not users'.
--
Jeremy
On Jan 25, 2007, at 5:50 PM, Jean-Sebastien Delfino wrote:
> Jeremy Boynes wrote:
>> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>>
>>> The C++ runtime allows bindings and component implementation
>>> types to share a common Tuscany namespace and updates to them do
>>> not require an update of the Kernel. We simply load the SCDL XSD
>>> files out of each runtime extension directory and they can
>>> contribute to a common namespace.
>>>
>>> As far as I know the Java runtime does not load or make any use
>>> of the SCDL XSDs at this point, so I don't understand what the
>>> issues would be with the Java runtime.
>>>
>>> The bindings and component implementation types defined by the
>>> OSOA specs are in a single OSOA namespace. I think that the
>>> bindings and component implementation types introduced by the
>>> Tuscany project should be in a single Tuscany namespace.
>>>
>>> Extensions provided by other projects can be in other namespaces
>>> obviously.
>>
>> How does this scheme address the versioning issues associated with
>> XML namespaces?
>
> Could you explain what you mean by this?
>
>>
>> The spec addresses them by coordinating releases from all binding
>> and implementation groups.
>
> Is that right? I am not aware that all specs sharing the OSOA
> namespace are going to be released at the same time. I understand
> that the SCA core namespace needs to be released before the
> extensions, but I can imagine different extensions being released
> independently. If there are dependencies between the various XSDs
> (for example a complex type extending another one) their updates
> obviously need to coordinated but this would be true with multiple
> namespaces as well.
>
>> Doing the same in Tuscany would take us back to a model where we
>> need to coordinate kernel and all extension releases which is
>> something we have decided not to do (for very good reasons).
>
> Like I said before I don't think that we need to update the kernel
> when extensions change. The Tuscany C++ runtime for example picks
> up extension XSDs from extension directories independent of the
> kernel, and is able to pick up newer versions of these XSDs without
> any change in the kernel. The Java runtime could do the same, but
> again at the moment it does not load or make any use of the XSDs
> anyway...
>
> I still don't see any concrete issue at this point.
>
>>
>> --
>> Jeremy
>>
>>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jeremy Boynes wrote:
> On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>>
>> The C++ runtime allows bindings and component implementation types to
>> share a common Tuscany namespace and updates to them do not require
>> an update of the Kernel. We simply load the SCDL XSD files out of
>> each runtime extension directory and they can contribute to a common
>> namespace.
>>
>> As far as I know the Java runtime does not load or make any use of
>> the SCDL XSDs at this point, so I don't understand what the issues
>> would be with the Java runtime.
>>
>> The bindings and component implementation types defined by the OSOA
>> specs are in a single OSOA namespace. I think that the bindings and
>> component implementation types introduced by the Tuscany project
>> should be in a single Tuscany namespace.
>>
>> Extensions provided by other projects can be in other namespaces
>> obviously.
>
> How does this scheme address the versioning issues associated with XML
> namespaces?
Could you explain what you mean by this?
>
> The spec addresses them by coordinating releases from all binding and
> implementation groups.
Is that right? I am not aware that all specs sharing the OSOA namespace
are going to be released at the same time. I understand that the SCA
core namespace needs to be released before the extensions, but I can
imagine different extensions being released independently. If there are
dependencies between the various XSDs (for example a complex type
extending another one) their updates obviously need to coordinated but
this would be true with multiple namespaces as well.
> Doing the same in Tuscany would take us back to a model where we need
> to coordinate kernel and all extension releases which is something we
> have decided not to do (for very good reasons).
Like I said before I don't think that we need to update the kernel when
extensions change. The Tuscany C++ runtime for example picks up
extension XSDs from extension directories independent of the kernel, and
is able to pick up newer versions of these XSDs without any change in
the kernel. The Java runtime could do the same, but again at the moment
it does not load or make any use of the XSDs anyway...
I still don't see any concrete issue at this point.
>
> --
> Jeremy
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
>
> The C++ runtime allows bindings and component implementation types
> to share a common Tuscany namespace and updates to them do not
> require an update of the Kernel. We simply load the SCDL XSD files
> out of each runtime extension directory and they can contribute to
> a common namespace.
>
> As far as I know the Java runtime does not load or make any use
> of the SCDL XSDs at this point, so I don't understand what the
> issues would be with the Java runtime.
>
> The bindings and component implementation types defined by the OSOA
> specs are in a single OSOA namespace. I think that the bindings and
> component implementation types introduced by the Tuscany project
> should be in a single Tuscany namespace.
>
> Extensions provided by other projects can be in other namespaces
> obviously.
How does this scheme address the versioning issues associated with
XML namespaces?
The spec addresses them by coordinating releases from all binding and
implementation groups. Doing the same in Tuscany would take us back
to a model where we need to coordinate kernel and all extension
releases which is something we have decided not to do (for very good
reasons).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>
> On Jan 24, 2007, at 1:54 AM, ant elder wrote:
>
>> On 1/24/07, Jeremy Boynes <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
The C++ runtime allows bindings and component implementation types to
share a common Tuscany namespace and updates to them do not require an
update of the Kernel. We simply load the SCDL XSD files out of each
runtime extension directory and they can contribute to a common namespace.
As far as I know the Java runtime does not load or make any use of the
SCDL XSDs at this point, so I don't understand what the issues would be
with the Java runtime.
The bindings and component implementation types defined by the OSOA
specs are in a single OSOA namespace. I think that the bindings and
component implementation types introduced by the Tuscany project should
be in a single Tuscany namespace.
Extensions provided by other projects can be in other namespaces obviously.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jim Marino <jm...@myromatours.com>.
On Jan 24, 2007, at 1:54 AM, ant elder wrote:
> On 1/24/07, Jeremy Boynes <jb...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 24, 2007, at 5:30 AM, Rick wrote:
> Hello,
> Not XML schema guru but in the assembly spec don't extension fall
> in XML schemas given under <any namespace="##other" ... and the
> "##other" imply a namespace other than the sca one ?
>
Yes, that's what I was referring to.
Also <implementation> and <binding> etc. all use substitution groups
to allow non-blessed versions from different namespaces.
This was specifically done by the spec to allow vendors implementing
it to release proprietary extensions independently. We need to do the
same with Tuscany extensions so that they too can be released
independently.
--
Jeremy
> ant elder wrote:
>> On 1/24/07, Jeremy Boynes <jb...@apache.org> 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? 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.
>> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Rick <cr...@gmail.com>.
Hello,
Not XML schema guru but in the assembly spec don't extension fall in XML schemas
given under <any namespace="##other" ... and the "##other" imply a namespace
other than the sca one ?
ant elder wrote:
> On 1/24/07, Jeremy Boynes <jb...@apache.org> 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? 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.
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by ant elder <an...@gmail.com>.
On 1/24/07, Jeremy Boynes <jb...@apache.org> 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? 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.
...ant
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
>
> --
> Jeremy
>
> On Jan 23, 2007, at 4:35 AM, ant elder (JIRA) wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> ant elder reassigned TUSCANY-1053:
>> ----------------------------------
>>
>> Assignee: ant elder
>>
>>> Use a Tuscany namespace for all non-spec'd Tuscany extensions
>>> -------------------------------------------------------------
>>>
>>> Key: TUSCANY-1053
>>> URL: https://issues.apache.org/jira/browse/TUSCANY-1053
>>> Project: Tuscany
>>> Issue Type: Improvement
>>> Affects Versions: Java-M2
>>> Reporter: ant elder
>>> Assigned To: ant elder
>>> Fix For: Java-SCA-M3
>>>
>>>
>>> Currently Tsucany extensions use SCDL elements is varrious different
>>> namespaces. There should be a single Tuscany namespace that
>>> extensions not defined by SCA spec's should use. See
>>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%3c45A27466.20504@apache.org%3e
>>>
>>
>> --This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Use a Tuscany namespace for all non-spec'd Tuscany extensions
Posted by Jeremy Boynes <jb...@apache.org>.
-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
--
Jeremy
On Jan 23, 2007, at 4:35 AM, ant elder (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/TUSCANY-1053?
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> ant elder reassigned TUSCANY-1053:
> ----------------------------------
>
> Assignee: ant elder
>
>> Use a Tuscany namespace for all non-spec'd Tuscany extensions
>> -------------------------------------------------------------
>>
>> Key: TUSCANY-1053
>> URL: https://issues.apache.org/jira/browse/
>> TUSCANY-1053
>> Project: Tuscany
>> Issue Type: Improvement
>> Affects Versions: Java-M2
>> Reporter: ant elder
>> Assigned To: ant elder
>> Fix For: Java-SCA-M3
>>
>>
>> Currently Tsucany extensions use SCDL elements is varrious
>> different namespaces. There should be a single Tuscany namespace
>> that extensions not defined by SCA spec's should use. See http://
>> mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/%
>> 3c45A27466.20504@apache.org%3e
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org