- From: George Cowe <gcowe@origoservices.com>
- Date: Tue, 25 Apr 2006 11:50:17 +0100
- To: paul.downey@bt.com, public-xsd-databinding@w3.org
>> 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.. >""" The schemas are different but belong in the same 'domain'. I will supply a cut down example to demonstrate this. A lot of the information supplied in the request is echoed back in the response but with additional information included (hence the request schema is almost a subset of the response schema). A particular domain (e.g. Quotes & New Business) has several product specific elements but also has several common elements (like policy-holder address). The namespace is shared across the domain which is represented by several product specific schemas each having a request and response schema. >> 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> This doesn't work when combining the schemas due the complex types with same name but differing content that appear in each of the separate schemas. We would need to rename elements in the schema to allow combining both the request and response into one schema. I think the tools have made a big assumption when it comes to the decision to use the namespace to name the packages. >> 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. When using the Eclipse 3.1.2 Web Tools Platform (WTP) plugins you are guided by a set of wizards in the graphical user interface. The option to use your own package names is not made available to the user. So this is one area where the dev tools which wrap data binding functionality into wizards need to be changed. We want to make it easy for developers to generate code so using the Eclipse framework and its wealth of plugins is ideal for this. The IBM Websphere toolset is Eclipse based and implements data binding in a similar way. So yes we would like to encourage vendors to improve toolkit support for features like this. >> 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. I will supply a small example to demonstrate this issue - I think this is the best way to present the use case and make it clear what's involved. >> 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. Agreed and I will do this. >> 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) Again the example should explain this. The root element of the request schema is the WSDL input message and the root element of the response schema is the WSDL output message. George >Paul
Received on Tuesday, 25 April 2006 11:03:49 UTC