xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brown, Keith" <KBr...@develop.com>
Subject RE: xml-soap and xsi:type requirements
Date Sat, 12 Aug 2000 00:18:39 GMT
Thanks for considering my plea. In the meantime, I added a feature that will
allow SOAP/Perl clients to explicitly specify a type so we can interop
immediately. FYI, I'm really close to getting SOAP/Perl interop with Apache
(I'll probably ship 0.24 early Monday).

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, August 11, 2000 1:26 PM
To: soap-dev@xml.apache.org
Subject: Re: xml-soap and xsi:type requirements

This is not too hard to add - here's a proposal on how to remove
the requirement that xsi:type be present for every element.

- the deserialization logic picks up the value of
  the xsi:type attribute and looks at it as a QName that is the
  type of the element.
- this type is then looked up in the mapping registry to find
  the appropriate deserializer.
What we can do is the following:
- if the xsi:type attribute is null, then use the QName of the 
  element as the type and look up a deserializer for it. 
- the user indicates the serializer by writing in the deployment
  descriptor this mapping (similar to what (s)he does now for
  the type QName).
- when we get schema support in, we just change the above to 
  first look up the element QName in the schema type lattice 
  and then do the de-serializer lookup.
A similar logic works for serialization.
This is trivial to implement and will allow APache SOAP to work 
without xsi:type being present. What do you think?

----- Original Message ----- 

From: Brown,  <mailto:KBrown@develop.com> Keith 
To: 'soap-dev@xml.apache.org' <mailto:'soap-dev@xml.apache.org'>  
Sent: Thursday, August 10, 2000 9:58 PM
Subject: xml-soap and xsi:type requirements

It's not clear to me why the Apache implementation requires xsi:type
attributes describing *all* parameters. Is there a way to turn off this
requirement? This would make it much easier to interop with environments
(like Perl) where type information is much more scarce (and not terribly
desirable). I'm guessing the reason for the requirement is for dealing with
overloaded method signatures?
Following is a thread I posted to the SOAP list recently for some
-----Original Message-----
From: Brown, Keith [mailto:KBrown@DEVELOP.COM]
Sent: Thursday, August 10, 2000 3:44 PM
Subject: [SOAP] SOAP/Perl progress report

I'm testing SOAP/Perl against the apache xml-soap implementation, and I now
see what you mean about type-encoding each element. They reject any requests
that don't have xsi:type attributes on all of the parameters.
I hacked my code to send all parameters as xsd:string, and now I get a fault
code of
which seems to indicate that I need to specify the actual types as opposed
to strings (or just use strings in all my test snippets ;-)
This isn't looking good from a Perl programmer's perspective - we don't have
that sort of type information in Perl.
Can anybody on the apache team help me here?

-----Original Message-----
From: Steven McDowall [mailto:sjm@APTEST.COM]
Sent: Tuesday, August 08, 2000 8:06 AM
Subject: Re: [SOAP] SOAP spec 1.1 and SOAP/Perl 0.23?

Hmm..How "compliant" is the question .. To which version?
Are you (which I did) going to type encode each element as 
xsi:type="xsd:string" so it works with an apache SOAP server?
with the proper constants, etc?
Just wondering

View raw message