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

Re: origin of interoperability problems?

Expand Messages
  • ejv02
    Hi, Your comments have beeen very interesting. Maybe I could summarise them as: although XSD is very powerful for describing type semantics, current toolkits
    Message 1 of 62 , May 6, 2005
      Hi,
      Your comments have beeen very interesting. Maybe I could summarise
      them as: although XSD is very powerful for describing type semantics,
      current toolkits don't support all the constructs and this produces
      impedance mismatches.

      But therefore I wonder: given the importance that XSD bindings have
      for interoperability, how is that the WS-I BP doesn't put any limit
      into the XSD constructs? If they do, toolkits would agree what it
      should be supported. In this sense, maybe the limit could be those
      constructs that were defined in the SOAP encoding soap1.1 section 5.
      What do you thing?

      Thanks in advance for your comments.
      Regards,
      -Enric

      ps. Regarding Anil's question about nillables types, I have read that
      .net 2.0 supports them. Reference:
      http://adrianba.net/archive/blog-5aa86125c57a40c3b3a22662304beb16.aspx





      --- In soapbuilders@yahoogroups.com, "John, Anil" <yahoo@k...> wrote:
      > >toolkits will simply continue to improve their support of the XML
      > Schema
      >
      > Agreed.
      >
      > >Unsupported schema constructs are OK as long as the toolkit
      > >allows a developer to mitigate the problem
      >
      > Unfortunately, in the current state of affairs is not half the issue
      > finding out exactly what is unsupported by the toolkit vendors? I am
      > curious to find out if the WS-I or anyone else currently have
      pointers
      > to any documentation from the various toolkit vendors that show
      exactly
      > which schema artifacts are currently unsupported by their products.
      I
      > for one would find such a document/collection of documents very
      helpful
      > in the choices that I need to make in implementing web services.
      >
      > Regards,
      >
      > - Anil
    • Steve Loughran
      ... 1. .net1.1 time assumes that times are in local tz, so if your service is working w/ GMT zones then you only get interop problems in the GMT locations. 2.
      Message 62 of 62 , Jul 5, 2005
        --- In soapbuilders@yahoogroups.com, Simon Fell <ws@z...> wrote:
        > >I've never personally had a dateTime problem, which in retrospect
        > >surprises me. Our users have a lot of confusion about timezones, but
        > >the interop is actually working the way it is supposed to.
        >
        > Steve Loughran has written a number of times about problems with
        > dateTime, i've never fully understood the issue he talks about,
        > although lots of users get confused over timezones, and whether there
        > toolkit works with UTC or local times (as most platforms DateTime
        > datatype typically doesn't retain TZ info).
        >

        1. .net1.1 time assumes that times are in local tz, so if your service
        is working w/ GMT zones then you only get interop problems in the GMT
        locations.

        2. Axis self tests were failing for me in the GMT0BST tz; nobody else
        could see it. wierd.

        3. I had an axis1.1 client/server where stuff was coming in a hour out
        on 127.0.0.1 based communications.

        Now, this is all in the past. Things may be fixed. Using time_t fixes
        things for me too mostly, though you have other problems there (leap
        seconds, the effect of the moon on the oceans, etc, etc). Try it and
        see. But remember to test not just in different systems, but in boxes
        (or at least virtual boxes) in different zones and locales.

        -steve
      Your message has been successfully submitted and would be delivered to recipients shortly.