[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]