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] V4 Discussion Item - approach to defining data structures and interfaces

From my perspective (and I may be misinterpreting John's intent), it
might be useful if the WSDL was actually tried in some real tools, and
perhaps that this exercise might feed into the structures of the API,
rather than the WSDL being generated almost as an after-thought.

For instance in the particular structure I brought up - there may have
been a better alternative which would have been "more compliant" with
the existing toolsets and which could have been suggested and used
instead if the creation and testing of the WSDL in toolsets was
performed in parallel with the creation of the specification.

There is, of course, an question of balance. Toolsets are evolving and
what isn't supported today may be supported tomorrow. Plus there are a
large (and growing) number of toolsets.


-----Original Message-----
From:	Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent:	Thu 20/03/2003 14:34
To:	Matthew Dovey; John Colgrave; uddi-spec@lists.oasis-open.org
Subject:	RE: [uddi-spec] V4 Discussion Item - approach to
defining data structures and interfaces

Actually, I am not sure if I got John's idea.
Is it all about the general V3 approach to include as many syntactical
restrictions in the UDDI XML schemas?
The example Matthew is talking about is one of several occurences in the
UDDI API XML schema where we specified an OR logic with XML schema.
Since XML schema directly only supports XOR logic with its "choice"
feature, we were forced to use an implicit OR logic (one or more
description elements OR one overviewURL element in the example).
There are many issues w.r.t. "complete" XML schema support in
tools/frameworks but I don't know how a separation of the syntactical
restrictions from the UDDI schemas (and perhaps a textual specification
instead) would help the mapping to programming interfaces.
-----Original Message-----
From: Matthew Dovey [mailto:matthew.dovey@las.ox.ac.uk] 
Sent: Mittwoch, 19. März 2003 13:52
To: John Colgrave; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] V4 Discussion Item - approach to defining data
structures and interfaces

> I think the time is approaching when programming interfaces for UDDI

> be

> able to be generated automatically from the UDDI WSDL descriptions.  I

> think

> we should take this into account when designing and describing the

> data

> structures and programming interfaces.


I'd support this.


I had (naively) assumed that it would have been possible to generate the
programming interfaces for UDDI from the WSDL (naively assuming that
this was supposed to be one of the benfits of WSDL!). Certainly as the
interface becomes more complicated, I'd argue that this is essential if
we want to see take up of UDDI.


In practice, I've find it difficult to generate the API's using the
existing published WSDL and the Axis java based toolkit. A major problem
has been unsupported XML Schema types in the Axis toolkits. At the last
attempt Axis 1.1 beta I think that there was one unsupported type which
I had to hack around. The problem at the moment (although I've not tried
the latest Axis 1.1 Rc2 yet) is when we hit structures of the form




The Axis toolkit would generate code of the form


String description[];

String overviewURL;

String overviewURL;


(the first overviewURL being from the first part of the choice within
the sequence, and the second from the second part of the choice).


I can't speak for other toolkits (so this may be a peculiarity of Axis)
or for the recent 1.1 RC2. In some of the other WebService work, I've
been involved with we have gone out of the way to make sure that ther
structures are such that the WSDL does pass through as many toolkits as
possible (in some cases at the expense of concise XML in the opinion of
some of the designers).




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