Hi !
Hm ... sorry ... one of my collegues changed the code to use soapvals
and you are right that the types came in because of that :-( We will
change back and try again ;-) Maybe I will come back with new questions.
But it was a really good answer ... now I see a little bit more clear ...
But what do you think of these empty namespace-attributes? I don't think
that they come from these soapvals ...
Ingo F
Scott Nichol wrote:
The literal in rpc/literal specifies that [de-]serialization of the XML
used in the service is completely specified by the WSDL, including the
XML Schema it contains. That is in contrast to rpc/encoded, where
encoded specifies that [de-]serialization of the XML used in the service
follows the rules of the SOAP 1.1 specification. Generally speaking,
this means that the contents of the SOAP Body element for rpc/literal
must conform to the XML Schema the WSDL uses to describe it. There is
no similar relationship between an XML Schema and a SOAP Body for
rpc/encoded.
This has many implications in practice, among which are
1. rpc/literal will generally not have xsi:type specified in SOAP Body
elements. It will usually only be present when the Schema specifies
xsd:any or a polymorphic data type (one that has "sub types" defined.
2. rpc/literal may represent null values with xsi:nil, but it also may
not, depending on the value of the nillable attribute for the
corresponding element in the Schema.
3. rpc/literal arrays look much different than rpc/encoded ones.
As for your first example. The presence of the xsi:type for the
elvBankName element is surprising. I would expect to see no type
information. This may be a NuSOAP issue. The representation of the
null value for elvBranchName may or may not be correct, depending on the
Schema. However, it is a known limitation of NuSOAP that the nillable
attribute of the Schema is not fully supported, so even if you want
xsi:nil in the SOAP message and thus specify nillable="true" in the
Schema, NuSOAP may not do the right thing.
The XML in your second example looks right except for the xsi:type for
elvCountries. I am somewhat surprised that NuSOAP specifies the type,
given the literal encoding.
I am not sure why the type information is present on some elements. My
rpc/literal sample does not put the type information in. Perhaps you
are using soapval values, which are used to force type information for
literal SOAP messages.
One last note. I believe that Microsoft still does not support
rpc/literal in .NET. Strangely, they do support rpc/encoded, even
though the WS-I Basic Profile prohibits it.
Scott Nichol
----- Original Message -----
From: "Ingo Fischer" <ingo.fischer@xxxxxxxx>
To: <nusoap-general@xxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, April 27, 2007 11:32 AM
Subject: [Nusoap-general] Problem with NULL and array values and
rpc/literal
Hi !
We are still trying to migrate one webservice from rep/encoded to
rpc/literal.
We have found one more problem which looks like a bug in nusoap:
In rpc/encoded the returned XML ist the following:
Encoded
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";>
<SOAP-ENV:Body>
<ns1:checkElvDataResponse
xmlns:ns1="https://ipayment.de/Shop3Service.xsd1";>
<elvBankName xsi:type="xsd:string">Sparkasse Offenburg-Ortenau,
Offenburg</elvBankName>
<elvBranchName xsi:nil="true" xsi:type="xsd:string"/>
</ns1:checkElvDataResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
so we return two values - one with a value and the second with "NULL" as
value.
The client is a Java-system and this rpc/encoded-response from the
webservice will work with them.
Now with rpc/literal the returned XML is slightly different:
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";>
<SOAP-ENV:Body>
<checkElvDataResponse
xmlns="https://ipayment.de/Shop3Service.xsd1";>
<elvBankName xsi:type="xsd:string">Sparkasse Offenburg-Ortenau,
Offenburg</elvBankName>
<elvBranchName/>
</checkElvDataResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The second value is missing the type information and the
"nil"-information.
Is this a bug or does rpc/literal await NULL-values that way?!
Any idea?
The second issue we have happends when returning an array or values:
We have a datatype which defines a list of countries in WSDL:
<xsd:complexType name="ElvCountryList">
<xsd:sequence>
<xsd:element
maxOccurs="unbounded"
minOccurs="0"
name="country"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
We return an array with the values here:
For rpc/encoded we use an array and everything works:
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";><SOAP-ENV:Body><ns1:getElv4AccountResponse
xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/";><elvCountries
xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[3]"><item
xsi:type="xsd:string">DE</item><item
xsi:type="xsd:string">AT</item><item
xsi:type="xsd:string">CH</item></elvCountries></ns1:getElv4AccountResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
For rpc/literal we changed the returned array to be "compatible" with
the way nusoap needs the data to generate the response (see earlier
email "[Nusoap-general] Changing Webservice from rpc/encoded to
doc/literal and Arrays"). But now in the generates webservice-reponse
there are empty namespaces and missing datatypes for the
"array-elements":
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:shop3="https://ipayment.de/Shop3Service.wsdl";><SOAP-ENV:Body><getElv4AccountResponse
xmlns="http://schemas.xmlsoap.org/soap/envelope/";><elvCountries
xsi:type="shop3:ElvCountryList"><country xmlns="">DE</country><country
xmlns="">AT</country><country
xmlns="">CH</country></elvCountries></getElv4AccountResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
Any idea here too? Maybe this is related ?!
Ingo Fischer
--
Ingo Fischer
_____________________________________________________________________
Ingo Fischer
1&1 Internet AG
Karlsruhe
Tel.: 0721/91374-0 Secure Internet-Payment:
http://www.1und1.de https://ipayment.de
_____________________________________________________________________
1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Achim Weiss,
Matthias Ehrlich, Andreas Gauger, Matthias Greve,
Robert Hoffmann
Aufsichtsratsvorsitzender: Michael Scheeren
smime.p7s
Description: S/MIME Cryptographic Signature
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/ _______________________________________________
Nusoap-general mailing list
Nusoap-general@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/nusoap-general
| 
