Hi Brian,
Unfortunately what is coming over on the wire is a invalid value for a
value type of type boolean. Without some added behaviors in your code, you
will not get the results you are looking for. If a <att nill=true/> were
being received, or if the field were omitted totally, you could probably
just attribute a default into the class that you are deserializing into,
but an empty field will not be perceived as nill (*nills on value types are
a different interoperability problem at the moment besides)
First I'd confirm that this bug is not possible to address on the sender's
side. That example of a "false" is definitely not intuitive, nor XML
compliant for a boolean value set. The easiest way to support your
position is to validate the data returned as XML against the schema for the
return. If the return type expected is a boolean, the empty value will
fail validation - and so as a caller you have a solid basis for calling
this a bug.
If you don't have the leverage to get this bug fixed, you probably will
need to intercept the data being returned, check for known problems and fix
the XML before it is sent to the deserialization step. The simplest way I
know to do this is to create a custom Web Service Extension that modifies
the incoming XML when the right conditions are met.
I hope this helps,
Dan Rogers
Microsoft Corporation
--------------------
Thread-Topic: Overloading SOAP Interpretations for Specific Primitive Types
thread-index: AcTMVkjJ7pj37CrRSJO5/fmbEgnuEw==
X-WBNR-Posting-Host: 210.8.233.77
From: "=?Utf-8?B?YnJpYW4ubWlsbHM=?="
