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

["Daniel Feygin" <feygin@unitspace.com>]

Simplifying the schema to support a greater variety of tools involves a
compromise between the conflicting goals of:
- specifying the data structures as precisely as XML Schema allows for
self-documentation and to enable automated schema-driven validation;
- being compatible with as many code-generation tools on the market as
possible.

By having just one schema we will have to continuously seek this compromise,
and as a result we will have a schema that is both incomplete (i.e. XML
Schema allows for a better match between the inherent information model and
the data structures we produce) and potentially not usable by some end users
implementing UDDI clients and servers.  In this case, native UDDI client
libraries will continue to proliferate, resulting in unnecessary learning,
support and lock-in concerns for client developers.

I find it worthwhile for the TC to produce two versions of the schema, which
will allow us to avoid both unwelcome outcomes.  Thus we would not
compromise the quality of the schema we produce due to the quality of the
tools on the market at a particular point in time while at the same time
making the schema usable by a diverse community of developers.  In fact, I
favor publishing the lite schema - should we choose to produce two versions
- as a BP or a TN rather than as part of the specification to avoid making
two normative versions of the schema, thereby making the lite schema a
useful implementation tool just as our other BPs and TNs are.  The scope of
such TN could be limited to just the JAX-RPC client developers.

I completely agree that JAXR is not particularly relevant to this
discussion.  It is a uniform API for accessing various XML registries - it's
value is in mapping multiple registries' information models and APIs to a
common denominator.  It may be viewed as an alternative technology that
allows clients to access UDDI, but it does not bypass UDDI API and so it
cannot be viewed as a substitute to UDDI WSDL and schema.

Daniel


> -----Original Message-----
> From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk] 
> Sent: Sunday, October 05, 2003 12:09 AM
> To: Ugo Corda; Anne Thomas Manes; John Colgrave; UDDI Spec TC
> 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
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members
/leave_workgroup.php.