Loading ...
Sorry, an error occurred while loading the content.

RE: [soapbuilders] Multiple xsi:type attributes

Expand Messages
  • Jacek Kopecky
    Simon, but it does. The client sends a request that contains data typed as xsd2001:string, just as the WSDL requests. The problem here is that neither SOAP nor
    Message 1 of 14 , Oct 2, 2001
    • 0 Attachment
      Simon,

      but it does. The client sends a request that contains data typed
      as xsd2001:string, just as the WSDL requests.

      The problem here is that neither SOAP nor WSDL say which Schema
      to use to specify the type. I don't think we should ban usage of
      different schemata. For example if I develop a schema language in
      the namespace "http://jacek.org/" and I use a qualified attribute
      'type' to express the type, the following is valid and correct as
      well (with the correct namespace decls):

      <inputString jacek:type="xsd1:string"
      xsi1:type="xsd1:string"
      >Simple Test String</inputString>

      And I guess this wouldn't even cause as much trouble as mixing
      together the different versions of XML Schemas, because (don't
      take it as an insult please) "people screwed up in their support
      for the three different Schema languages and they are mixing
      them".

      The xsi:type typing mechanism is a part of the XML Schema, not
      of SOAP or of XML.

      Best regards

      Jacek Kopecky

      Idoox
      http://www.idoox.com/



      On Tue, 2 Oct 2001, Simon Fell wrote:

      > surely, in that case the same argument can be made for the client. It has
      > the WSDL, why doesn't it just send a 2001 request, as indicated in the WSDL
      > ?
      >
      > Cheers
      > Simon
      >
      > -----Original Message-----
      > From: Jacek Kopecky [mailto:jacek@...]
      > Sent: Tuesday, October 02, 2001 9:54 AM
      > To: soapbuilders@yahoogroups.com
      > Subject: Re: [soapbuilders] Multiple xsi:type attributes
      >
      >
      > Paul,
      > please see my comments inside.
      >
      > Jacek Kopecky
      >
      > Idoox
      > http://www.idoox.com/
      >
      >
      >
      > On Tue, 2 Oct 2001, Paul Kulchenko wrote:
      >
      > > Hi, Martin!
      > >
      > > I also thought this idea will work, but now I don't think so ;). What
      > > schema you expect to get in response? Forget about WSDL for a second.
      > > You send a message that has 1999 and 2001. What would you like to get
      > > back? From server that understands only 2001 -- 2001, from 1999 --
      > > 1999, but what if server understands both?
      >
      > If the server doesn't understand 2001, it won't understand the
      > xsd2001:string type.
      >
      > Anyhow, in the no-WSDL case, and assuming the server understood
      > the xsd2001:string type as e.g. java.lang.String, the server must
      > have a mapping from its native types (e.g. java.lang.String) to
      > the schema types (e.g. xsd1999:string). Then it will respond with
      > the xsd1999:string type no matter what because it knows it was a
      > java.lang.String before serialization.
      >
      > This mapping can be automagically tweaked depending on what the
      > incoming message contained. This is heuristics, bound to fail in
      > some cases.
      >
      > But anyway, in case the server's got the WSDL, it should respond
      > with xsd2001:string.
      >
      > > To make it absolutely predictable, I need to use 1999 as lowest
      > > common denominator, regardless of what WSDL or other description
      > > says.
      > >
      > > In my opinion this is not the best way to solve possible interop
      > > problems between different XML Schemas.
      >
      > IMHO the best way to solve possible interop problems is a
      > mathematically strict spec. We don't have that. I think this
      > approach (sending the type information three times) is OK.
      >
      > > Best wishes, Paul.
      > >
      >
      > Same to you,
      >
      > Jacek
      >
      >
      >
      > -----------------------------------------------------------------
      > 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:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
      > -----------------------------------------------------------------
      > 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:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Jacek Kopecky
      Pete, please see my comments inside. 8-) ... Pete, there is no conflict in a message that says three times the exactly same information. The message is
      Message 2 of 14 , Oct 2, 2001
      • 0 Attachment
        Pete, please see my comments inside. 8-)

        On Tue, 2 Oct 2001, Pete Hendry wrote:

        > I understand what Martin is doing, I just don't see why
        > anyone would want to do it and why it should be supported
        > for interop. Your example above is completely lost on me as
        > to relevance to a SOAP message! Why would someone want to
        > mix schema version in a SOAP message (or for that matter,
        > in a WSDL document describing a service)??

        Pete, there is no conflict in a message that says three times the
        exactly same information. The message is completely valid.

        > I'd rather concentrate on getting useful stuff working
        > rather than degenerate into a 'my toolkit can do this so
        > maybe it should be an interop test'!

        I don't think this is a feature of WASP C++, I think this is a
        bug of the toolkits that get confused by this, and I think fixing
        bugs is useful. I can see, however, how this particular bug can
        be a very low-priority one. 8-)

        Jacek Kopecky
      Your message has been successfully submitted and would be delivered to recipients shortly.