[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code generation
> First of all, we should use JAX-RPC 1.1 as a reference point, > not JAX-RPC 1.0. Among other things, the latest version of > JAX-RPC has been modified to support WS-I, and it will be the > version required by J2EE 1.4. Thanks for the clarification and restoring my faith - I was finding it surprising that the JAX-RPC folk weren't aware of the growing gap between JAX-RPC and WS-I... > The first Appendix, "XML Schema Support", has also been > modified, and we should double check whether the mapping > problems encountered in JAX-RPC 1.0 are still present in 1.1. > (It looks like there is still a little bit of contradiction > with R2800 from the WS-I Basic Profile 1.0, since the JAX-RPC > 1.1 Appendix still says "Any XML data types not listed in > this section are not required to be supported by a JAX-RPC > implementation"). I think in practice that there will be some XML Schema constructs that tools and language defined bindings such as JAX-RPC may not handle well due to the complexity of XML Schema. Also it seems likely that a less mature tool will handle a smaller subset of XML Schema that a more mature one (and WebServices is still a relative new technology). I don't think we need two WSDL/WSDL Schemas. In any case I would be looking to auto-generate both server stubs and clients from the WSDL not just clients, and John's suggestion of having a cut-down schema is only aimed at client developers (which admittedly is probably a larger community). My own view is that we should not over complicate the constructs used in the UDDI WSDL/XML Schema to the point that many auto-generator tools will struggle, but that we shouldn't bend over backwards either. Unfortunately at present there aren't any good ways of investigating this apart from suck-it-and-see tests with various tools. The JAX-RPC 1.1 appendix might give some clues as to what might be considered XML Schema constructs that are likely to be overly complex for tools to implement, otherwise having some regression-type testbed attempting to compile the WSDL using a number of well known tools (.Net, Axis, gSOAP etc.) may assist. At some point there will be an element of judgement e.g. the <choice> <element name="one".. <sequence> <element name="one".. <element name="two".. </sequence> </choice> Construct which Axis (at least as of July) chokes on, is in my opinion, a bug in Axis, rather than a problem with the UDDI WSDL... Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]