RE: [soapbuilders] Re: Where's decimal?
- hi there,
i don't think that these representations need to be
part of SOAP. i just think it would be great if the
java guys agree on a format for encoding common java
data structures. once a few do this, the others are
likely to use the same format.
this is what is already happening on a small scale.
after all, there is no documentation that i'm aware
of that says that a java int maps onto an XML schema
C++, C#, Perl guys, etc. can do whatever they want.
they could decided to use the java mapping and map
this onto their language, or use something else.
ideally, the java<->xml schema mapping is language
independent to improve the chances of this happening.
From: Rosimildo daSIlva [mailto:rosimildo@...]
Sent: Monday, July 02, 2001 5:14 PM
Subject: RE: [soapbuilders] Re: Where's decimal?
--- Yann Christensen <yannc@...> wrote:
> > Ideally, on the client side, no changes should beI guess you have not seen the messy that BOA was...
> needed. Maybe some
> You seem to be suggesting that SOAP should evolve to
> not only describe a
> wire format but also a programming API. I think that
> would be a mistake.
> Why should different programming
> environments/languages have to adhere
> to a common API? Undoubtedly you would end up with
> some sort of least
> common denominator feature set. I prefer for the
> standards to focus on
> the wire formats and let the toolkits decide how it
> maps best into their
> Now I think it is interesting to look at defining
> recognizable patterns
> for common complex data structures. Though I think
> that would best occur
> in XML Schema since that defines the common type
> system across the
> various toolkits.
people maintain it, still have nightmares...
I do not think these things belong to SOAP.
SOAP is what it is. A wire level protocol.
The same as IIOP is for CORBA.
I can tell you want thing, I have been working on this
area long enough, to dare to say, that in one way
or the other, mapping from WSDL to programming
languages will come. It is just a matter of time.
I do not think that these mappings have anything
to do with SOAP, maybe more with XML schema or
Have a good one.
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
This group is a forum for builders of SOAP implementations to discuss
implementation and interoperability issues. Please stay on-topic.
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Thanks for the tip, the web.config entry worked great.
I'm now trying to get a .Net (beta 2) client calling a very simple
helloworld Apache SOAP (v2.2) service with one string in and a string
return. After jumping through many hoops already, I am close but
still get this error:
<faultcode>SOAP-ENV:Client</faultcode> <faultstring>No Deserializer
found to deserialize a ':meth1_inType1' using encoding
The type attribute for meth1_inType1 is defined as xsd:string. The
equivalent java client works fine and comparing the .net vs. java raw
soap requests, there are only 2 differences. 1) 1999 vs. 2001 XML
Schema namespaces and 2) the encodingStyle attribute is on the 'Body'
tag vs. on the 'helloworld' (method) tag. I read in Apache's doc's
that 2001 schema would be deserialized correctly, but haven't tested
this myself. Also, haven't found a way to tell .Net to put the
encodingStyle attribute on a different tag to test if that
specifically causes the fault.
Any suggestions as to how I can get this simple interoperability test
--- In soapbuilders@y..., "Alex DeJarnatt" <alexdej@m...> wrote:
> Paul, I can address the 3 issues you encountered. However, only one
> them can be fixed on the .NET side...
> 1. the binding attribute of port and the type attribute of binding
> QNames. The generated WSDL is correct. That said, this seems to be a
> common mistake -- a good number of the WSDLs on xmethods don't use
> QNames. Perhaps there's a newer import tool you could use that
> 2. ASP.NET web services beta 2 support WSDL 1.1, which requires use
> the 2001 XML Schema. Again, perhaps there's a newer import tool you
> could get...
> 3. the WSDL for get and post should be spec-compliant according to
> rules of WSDL section 4, but it's reasonable to not want to include
> in your generated WSDL if you're not interested in using get or
> You can turn off support for GET and POST on a per-appdir basis by
> putting the following in a file called web.config in the same
> as your .asmx
> <remove name="HttpGet"/>
> <remove name="HttpPost"/>
> -----Original Message-----
> From: Paul Welch [mailto:paulwelch28@y...]
> Sent: Wednesday, July 11, 2001 2:21 PM
> To: soapbuilders@y...
> Subject: [soapbuilders] Re: .NET encoding stuff
> I've been trying to work through the .Net to IBM WSTK WSDL
> compatibility. I've made it all the way from .Net Web Service to a
> working auto-generated java client proxy, but only with several
> manual edits of the WSDL. I have a .Net service with the following
> attributes specified:
> at the class level:
> [SoapRpcServiceAttribute(RoutingStyle =
> and, at the method level:
> [SoapRpcMethodAttribute( "http://www.divine.com/",
> Even though it's generated in RPC style, the .Net WSDL still has
> several incompatibilities with the IBM WSTK proxygen utility
> (using .Net Studio beta 2 and IBM WSTK V2.3). The ones I've
> identified so far are:
> - Different Rules for Resolving Fully Qualified Definitions: For
> instance, .Net creates a s0 namespace (tempuri.com by default) and
> tries to qualify types to s0 that are actually defined in the
> document. The proxygen does not appear to look in the current
> document for fully qualified types. My solution so far has been to
> delete "s0:" qualifications from these, including the <port
> <binding type>, etc.
> - Different Levels of Support for XML Schema: .Net generates 2001
> Schema namespace, IBM WSTK expects 1999. So far, changing the WSDL
> to 1999 has worked.
> - HTTP Get/Post Support: I need to research this one further,
> however proxygen does not accept the .Net generated definitions for
> these. I was more interested in getting the SOAP binding to work,
> I haven't spent much time on it yet.
> I realize this is a short-term problem until the tools are more
> mature, but are there any solutions that might be more elegant than
> directly editing the WSDL, such as additional .Net attributes, etc.?
> Thanks in advance for any suggestions...
> Best Regards,