[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSRF81: Investigations and proposed resolution
Background ------------------ Issue 81 says: "Some tooling does not correctly handle xsd:include." The second sentence "WS-I compliance requires that xsd:include not be used. " was countered by Peter Niblett in http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200411/msg00015.html The email by Glenn here http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200410/msg00113.html reported a bug in MS tools, but there are also issues in processing of <xsd:include> by other tools based on WSDL2Java, namely different ways of handling multiple <xsd:include> elements for the same inclusion such as: <xsd:schema> <xsd:include schemaLocation="L"> <xsd:include schemaLocation="L"> <... Some tools report as errors the duplicate definitions brought in by the second inclusion. Some don't. Reporting this construction as an error seems to be a mistake according to the following note in section 4.2.1 of http://www.w3.org/TR/xmlschema-1: "Note: The above is carefully worded so that multiple <include>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 <include>ing the same schema document more than once to forestall the necessity of establishing identity component by component." Suppose WS resource 'A' is constructed from an xsd file which defines complex types and resource property elements, and a wsdl file with an embedded schema. The embedded schema includes the xsd (via <xsd:include>), defines message body elements and assembles the Resource Properties document. The specs are constucted like this, and any WS Resource could be constructed in the same way, which seems intuitive, to me. If a WS Resource 'B' wants to extend a WS Resource 'A' which is constructed in this way, 'B' must: 1. <wsdl:import> 'A's wsdl to get the message definitions 2. Copy/paste the operations (which refer to the message defs) into a new portType 3. <xsd:import> 'A's xsd into the wsdl:types/xsd:schema to get the Resource Property element definitions 4. Construct a Resource Properties document in wsdl:types/xsd:schema and refer to it from the new portType. Now, some tools report 'B's wsdl as valid, but some report it as invalid because of duplicate definitions included indirectly by step 1. and included directly by step 3. Thanks to Ian Robinson for this discovery. So, since ServiceGroup.wsdl extends ResourceProperties.wsdl, it is 'invalid', according to some tools. And since ServiceGroup uses the <include> technique, ServiceGroupRegistration is 'invalid' too, since it extends ServiceGroup. Proposal ------------- The proposal by Glenn was to use to change the targetnamespace of wsdl:types/xsd:schema to allow the use of xsd:import instead of xsd:include This avoids the MS bug. Luckily, this also avoids the errors reported by tools based on WSDL2Java since it is tolerant of multiple <xsd:import> elements for the same namespace. A note in section 4.2.2 of http://www.w3.org/TR/xmlschema-1 advises that this tolerance is required. Apart for waiting for tools changes, which leaves WSRF hostage to fortune, there are three ways to solve the problem: a) Use the .wsdl targetnamespace in wsdl:types/xsd:schema b) Introduce a new targetnamespace c) SteveG's suggestion: remove all schema components to the xsd file and use no targetnamespace on the wsdl:types/xsd:schema. BaseFaults already uses this technique. a) is counter to what seems to be the established constuction of wsdl which is described in the WSDL 2 primer (see http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html) Here the wsdl:types/xsd:schema uses an '.xsd.' targetnamespace. b) Seems awkward, c) Is simplest. I like this option best, even in spite of this rule in WSDL 2.0 (found by IanR) " 3.1.2.1 targetNamespace attribute information item The targetNamespace attribute information item defines the namespace of the element declarations and type definitions embedded in its [owner] xs:schema element information item. WSDL modifies the XML Schema definition of the xs:schema element information item to make this attribute information item required." Let's cross that bridge when we reach it. Regards, Tim Banks IBM TP Architecture & Technology. Hursley, UK. Phone: External +44 1962 815639, Internal 245639
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]