RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code generation

["Matthew J. Dovey" <matthew.dovey@oucs.ox.ac.uk>]

> 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