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