Return-Path: Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list soap-dev@xml.apache.org Received: (qmail 13890 invoked from network); 11 Aug 2000 20:37:55 -0000 Received: from mail.activcard.com (HELO hub1.hub.activcard.com) (207.93.240.18) by locus.apache.org with SMTP; 11 Aug 2000 20:37:55 -0000 Received: from usexchg1.activcard.com (USEXCHG1 [192.168.133.9]) by hub1.hub.activcard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N60FYQLM; Fri, 11 Aug 2000 13:37:59 -0700 Received: by USEXCHG1 with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 13:32:48 -0700 Message-ID: From: Jean-Noel Gadreau To: "'soap-dev@xml.apache.org'" Subject: RE: xml-soap and xsi:type requirements Date: Fri, 11 Aug 2000 13:32:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C003D3.4FB8E8F8" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C003D3.4FB8E8F8 Content-Type: text/plain; charset="iso-8859-1" Sounds like a good idea. Jean-Noel ============= Jean-Noel GADREAU Software Engineer, ActivCard Inc.( http://www.activcard.com ) E-mail: jngadreau@activcard.com Tel (main): 510-574-0100 Tel (direct): 510-574-1736 -----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. Currently: - 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? Sanjiva. ----- Original Message ----- From: Brown, Keith To: '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 background. Keith -----Original Message----- From: Brown, Keith [mailto:KBrown@DEVELOP.COM] Sent: Thursday, August 10, 2000 3:44 PM To: SOAP@DISCUSS.DEVELOP.COM 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 org/apache/soap/util/MethodUtils$MoreSpecific 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? Keith -----Original Message----- From: Steven McDowall [mailto:sjm@APTEST.COM] Sent: Tuesday, August 08, 2000 8:06 AM To: SOAP@DISCUSS.DEVELOP.COM 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 -Steve ------_=_NextPart_001_01C003D3.4FB8E8F8 Content-Type: text/html; charset="iso-8859-1" RE: [SOAP] SOAP spec 1.1 and SOAP/Perl 0.23?
Sounds like a good idea.
 
Jean-Noel

=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736

-----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.

Currently:
- 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?

Sanjiva.
 
----- Original Message -----
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 background.
 
Keith
 
-----Original Message-----
From: Brown, Keith [mailto:KBrown@DEVELOP.COM]
Sent: Thursday, August 10, 2000 3:44 PM
To: SOAP@DISCUSS.DEVELOP.COM
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
<faultstring>org/apache/soap/util/MethodUtils$MoreSpecific</faultstring>
 
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?
 
Keith
-----Original Message-----
From: Steven McDowall [mailto:sjm@APTEST.COM]
Sent: Tuesday, August 08, 2000 8:06 AM
To: SOAP@DISCUSS.DEVELOP.COM
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
 
-Steve
------_=_NextPart_001_01C003D3.4FB8E8F8--