6432Re: [soapbuilders] Re: jSOAP and MSSOAP3.0 client test results
- Dec 9, 2001On Fri, Dec 07, 2001 at 10:04:07AM -0600, Matt Long wrote:
> ... However, I suppose you could restrict the simpleTypeThis makes sense to me (with my limited schema/WSDL knowledge).
> by referencing a simpleType in the wsdl schema with a restriction that
> nillable='false', thus clearly describing the context of the part.
> Does this make sense?
> <definitions xmlns="wsdl-namespace"
> xmlns:s="http://soapinterog.org/xsd" />
> <schema targetNamespace="http://soapinterop.org/xsd"
> <simpleType name="nonNillableString">
> <restriction base="string">
> <nonNillableString nillable="false"/>
> <message name="echoStringRequest">
> <part name="inputString" type="s:nonNillableString"/>
> <message name="echoStringResponse">
> <part name="inputString type="s:nonNillableString">
Do most people support this? Could it become the 'recommended
WSDL solution to nil/non-nil parameters'? (Should I be asking
this on a WSDL list instead :-)
I know SOAP allows nil's to be encoded - but that is not the
question. Does the above WSDL successfully say 'inputString
cannot be nil' and without the above does it mean 'inputString
can be nil'? This impacts the current interop tests as to
if sending a nil is OK or not with the WSDL file currently
This is one of the final areas where I don't really have a
satisfactory answer to - other areas (such as p-t-a and sparse)
I believe I fully understand the current position of SOAP
(I might not like it, but I understand it :-). Nil's for parameters
was the final area of 'lack of functionality' to me.
Then, if the above is the correct way to go, should the current
interop tests allow or exclude nil? Or both? Or just leave it
as it is (which is fine by me).
- << Previous post in topic