OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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


Mathew,

I absolutely agree with your point.

On the other hand, why would I worry about the WSDLs if I do my coding in
.NET (MS provides an object model) or Java (JAXR)?

What are the other common platforms that we need object models for?
C++ for Win
C++ for Unix
Perl
Python
Any others?

I think it's an implementation issue. We may want to think how to encourage
code sharing for those non-mainstream platforms.

Cheers,
Max

----- Original Message ----- 
From: "Matthew J. Dovey" <matthew.dovey@oucs.ox.ac.uk>
To: "Daniel Feygin" <feygin@unitspace.com>; "Ugo Corda"
<UCorda@SeeBeyond.com>; "Anne Thomas Manes" <anne@manes.net>; "John
Colgrave" <colgrave@hursley.ibm.com>; "UDDI Spec TC"
<uddi-spec@lists.oasis-open.org>
Sent: Monday, October 06, 2003 9:07 AM
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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]