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

["John Colgrave" <colgrave@hursley.ibm.com>]

I meant iii)

I think I mentioned in my original note that I am unaware of any clients
that do schema validation, even of responses let alone of requests, so I
must admit that I did not consider this danger.

My intention was to allow the automatic generation of a client that a
programmer could use to generate a valid request as long as they followed
the rules in the spec. and the normative schema.

They could generate an invalid request but it should be fairly easy to
figure out the problem from the normative schema and the spec.

As has been pointed out, even the current hand-crafted UDDI clients can send
invalid requests so I don't think the proposed approach would be any worse.

There is another approach which is to change the on-the-wire structures in
ways which accommodate the tools but I don't favour that, so relaxing the
schemas that tools use in a way that is interoperable with registry
implementations, that are assumed to be using the normative schemas, seems
to me to be the best approach.

As for the issue of uniqueness and persistence and XML namespaces, I agree
that it would not be ideal to have two different definitions of some
entities in the same namespace, but I can't think of a pragmatic
alternative.

John Colgrave
IBM


> -----Original Message-----
> From: Daniel Feygin [mailto:feygin@unitspace.com]
> Sent: 06 October 2003 11:47
> To: 'Matthew J. Dovey'; 'Ugo Corda'; 'Anne Thomas Manes'; 'John Colgrave';
> 'UDDI Spec TC'
> Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code
> generation
> 
> Matthew,
> 
> I agree that (i) is a no-brainer and we should avoid unnecessary use of
> unnecessarily verbose structures that add no additional value. :))
> 
> I am not advocating (ii).
> 
> (iii) is the interesting case, which is the one I though we had been
> discussing all along.  Certainly some clients would be able to form
> requests
> that are compliant to the lite schema, but fail validation under the
> normative schema.  But without a JAX-RPC-compatible schema these clients
> would not be able to form *any* kind of requests, so lite schema is still
> progress in the right direction.  After all, even using the current
> normative schema clients can form a wide variety of invalid requests that
> are schema-compliant (how about a <find_business generic="2.0"/> for
> one?).
> 
> Developers who use code generation tools that are fully compliant to XML
> Schema can use the normative schema and take advantage of schema-driven
> validation to the degree their tools support it.  For developers who don't
> use tools that are fully compliant to XML Schema there is nothing we can
> do
> to enable schema-driven validation other than providing a lite schema.
> 
> I am afraid what you refer to as dangerous is in fact providing better
> value
> to the developer using superior tools.  The programmer scratching his head
> over server-side validation errors must have a pretty good idea that he
> used
> a lite schema on his limited-capability code generation tool to create a
> limited-validation stub.  This is something he should be aware of from
> reading the supporting documentation.  I believe making this lite schema a
> part of BP scoped to JAX-RPC client development is an appropriate format.
> Other interested parties may want to contribute similar BPs for other
> popular platforms and tools that may struggle when processing the
> normative
> UDDI schema.
> 
> Daniel
> 
> 
> > -----Original Message-----
> > From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk]
> > Sent: Monday, October 06, 2003 12:08 AM
> > To: Daniel Feygin; Ugo Corda; Anne Thomas Manes; John
> > Colgrave; UDDI Spec TC
> > Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to
> > support code generation
> >
> >
> > I'm not convinced. As far as I can tell this lite schema will
> > do either one of three things:
> >
> > i) specify exactly the same on the wire structures but using
> > different expressions. XML schema does allow you to say the
> > same thing in different ways. However, if the lite schema is
> > just another way of saying the same as the normative schema
> > but in a less complex way, I would question the need for the
> > more complex schema.
> >
> > ii) the lite schema specifies a smaller simplified API - in
> > which case we should just create a new smaller simplified API
> > - UDDI-lite?
> >
> > iii) the lite schema approximates to the normative schema,
> > for example doing things such as using sequences instead of
> > choices but with some covering text that only one of the
> > elements should be present. This sounds dangerous to me, in
> > that an client which does schema validation could send
> > something which it validates to a server which then
> > SOAP-faults it as not validating. I can imagine many a
> > programmer scratching their head over that one...
> >
> > Also both ii and iii (more so ii) aren't really in the spirit
> > of the uniqueness and persistence of XML namespaces, in that
> > two different schemas would share a namespace...
> >
> > Matthew
> >
> > > -----Original Message-----
> > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > Sent: Sunday, October 05, 2003 2:24 PM
> > > To: Matthew J. Dovey; 'Ugo Corda'; 'Anne Thomas Manes'; 'John
> > > Colgrave'; 'UDDI Spec TC'
> > > Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to
> > > support code generation
> > >
> > > 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.
> > >
> > >
> > >
> >
> > 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.