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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
