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

Title: Message
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 will

> be

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

> think

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

> 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]