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