W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > April 2006

RE: ISSUE-34: multiple schemas for a single namespace

From: <paul.downey@bt.com>
Date: Fri, 21 Apr 2006 18:33:13 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC95225504BFE903@I2KM11-UKBR.domain1.systemhost.net>
To: <public-xsd-databinding@w3.org>, <gcowe@origoservices.com>

> Raised by: Paul Downey

actually raised by George, but Tracker doesn't seem
to know about George, yet!

> When we implement a messaging service we typically have two schemas one for
> the request and one for the response. Each will share the same namespace.

XML Schema 1.0 Part 1 Notes:

multiple <import>ing of the same schema document will not 
constitute a violation of clause 2 of Schema Properties Correct 
(§3.15.6), but applications are allowed, indeed encouraged, to 
avoid <import>ing the same schema document more than once to 
forestall the necessity of establishing identity component by component. 

> In WSDL we have a request-response service with a request message 
> and a response message defined separately.

you might like to consider including the two schemas into a single
schema, e.g.:

<schema targetNamespace="serviceNamespace" ...>
   <include schemaLocation="request.xsd"/>
   <include schemaLocation="response.xsd"/>

> When using data binding tools to generate code from the WSDL (Apache Axis 1.3
> WSDL2Java in our case) the target namespace is used to name the packages
> containing the generated classes.

OK, but there is usually an override to assert a package name
for generated classes, this seems like something we could
encourage toolkits to support.

> This causes a problem because the namespace in both schemas 
> are the same. This results in the data binding tool attempting 
> to use the same package name for
> both the classes representing the request and response schemas.

> When element names collide in both schemas then only the element 
> defined in the first schema (the request schema) is processed. 
> Note that element names are the
> same but their structure will often be different (the response 
> typically is more complex than the request).

So the namespaces are the same and the elements the same, but
their definitions differ? This seems like slightly different
to the use-case I'd imagined for above where the namespace 
is an assembly of elements and types split across two schemas.

This sounds similar to a versioning use case where the namespace
doesn't change, though the description used depends upon the 

> There are a number of ways to work around this problem including
> Ā·        Make the namespaces unique
> Ā·        Donā?Tt use data-binding tools

Is it just databinding tools that bail for this use-case?

It might help if you could submit a simple Schema or
WSDL example and we can test it with other tools.

> We believe we are using schema namespacing correctly so are 
> reluctant to do make changes to them as this would cause a 
> proliferation of namespaces for us. 

I think it's ok to have two schemas for a given namespace
with different elements and types (after all it's just a 
description of the elements and types a process may expect
to send and receive within a given context). 

However, I'm convinced it's not OK to put two schemas inline
in the same WSDL with the same namespace but different 
declarations and expect it to work - how does the WSDL 
processor know which message element qname to follow?
(I may be missing the point here)

Received on Friday, 21 April 2006 17:33:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:12 UTC