Forum OpenACS Development: Re: Tcl Web Services Toolkit: TWiST
As the developer of wsdlpull,somebody brought my attention to
this bug. as far as i understand its a bug in simple types.One such bug is caused by the creating another type DayNumber which is just a wrapper for "daynumber" note the case. Due to this the check for valid integers in the enumeration fails for the 3rd operation in the http://junom.com/ws/datetime/?WSDL because wsdlpull does not check validity recursively up the type tree yet. I am workin on fixing this but an immediate fix would be to remove the (redundant ,IMHO)wrapper
type "DayNumber". Feel free to contact me if you do have issues in wsdlpull
vivek Krishna mailto:email@example.com
Thanks for keeping track of this discussion. Personally I like wsdlpull, which is why I provided links to your software. I immediately recognized limitations for the built in client 'wsdl'. These limitations are to be expected in this field, especially with a simple example use of the API. The point is that the WSDL is correct, but individual clients may not take into account every conceivable representation of data types. This is not necessarily a bug for the client. In my opinion, XML Schema provides so many ways to represent the same structures, that it is unreasonable to expect independent client and server software to 'understand' each other.
I agree with Vivek that there is an unnecessary, although legal, layer (at the moment) in the type definitions of TWiST. This will be removed as I have stated before. But this fix will not make wsdlpull interoperate fully with TWiST. There will still be limitations with types based upon patterns and complexTypes beyond what a simple array could represent. My understanding is that the 'wsdl' client of wsdlpull is merely an example use of the underlying API. I like it, and it helps me check for certain errors. But it is unreasonable to expect that any client or server will ever support much of the XML Schema standard for type definition. There are a handful of companies investing billions into this problem with little success. XML Schema is something of a disaster in flexibility. In response, I have placed well defined limits on how types are represented in tWSDL.
As Vivek has mentioned, a tool in the cure is to represent types as a tree going back to the built in types. I wish to use a tree so that the XML Schema is as simple as possible, but this might also help the clients. At least clients can apply a rational and consistent process in reading the WSDL and developing the type validation code. However, as an intermediate step, or maybe a final step I have decided to flatten the type hierarchy. Every complexType is at a global level, allowing it to be reused as a child of other complexTypes. Elements with a simpleType content will be protected inside their parent elements, but their simpleType will be exposed as a global type in the case that the type is a derived type. But as I said, even this simplification will not guarantee that the wsdlpull client will interoperate in every case.