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

[Anne Thomas Manes <anne@manes.net>]

I was, in fact citing and quoting JAX-RPC 1.1. Although Sun claims that 
JAX-RPC 1.1 is WS-I compliant, it does not comply with WS-I rule:

    R2800 A DESCRIPTION MAY use any construct from XML Schema 1.0.

JAX-RPC 1.1 says that support for a number of XML Schema structures is 
optional. See the XML Schema appendix, Table 18-1, page 134. A JAX-RPC 
implementation is not required to support the following structures:
- union
- nested arrays
- arrays with instances of any subtype of the specified array type
- anyType
- choice
- group
- derivation of complex types by restriction
- abstract types
- derived types -- final, fixed, or block attributes
- ENTITY, NOTATION, IDREF

Given that the JAX-RPC spec is not compliant with WS-I, I don't think we 
should constrain our WSDLs to the XML subset defined by Sun.

I agree with Matthew that lack of support for xsd:choice is a bug in an 
implementation -- whether or not it is a requirement in JAX-RPC.

Anne

At 09:08 PM 10/4/2003 +0100, you wrote:
> > 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