xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: xml-soap and xsi:type requirements
Date Fri, 11 Aug 2000 22:52:09 GMT
RE: [SOAP] SOAP spec 1.1 and SOAP/Perl 0.23?I think it is probably the best
approach to take.  Developers will just have to know that if they want the
code to work with other SOAP implementations, then they have to declare the
mappings in the deployment descriptor.  This is perhaps the biggest
argument, so far, for at least rolling in basic schema or SDL/SCL/NASSL
support as soon as possible though.  Even just a rudimentary SDL/NASSL
processor that queries the schema data types would be sufficient, never mind
any of the more advanced concepts.

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

Mime
View raw message