- From: <paul.downey@bt.com>
- Date: Fri, 21 Apr 2006 18:33:13 +0100
- 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: http://www.w3.org/TR/xmlschema-1/#composition-schemaImport """ 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"/> </schema> > 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 context. > 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) Paul
Received on Friday, 21 April 2006 17:33:25 UTC