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

Re: [soapbuilders] Re: origin of interoperability problems?

Expand Messages
  • Glen Daniels
    Hi Erik, all: ... I understand the argument, but respectfully disagree... :) - a little. Although it is certainly true that XSD does not describe semantics
    Message 1 of 62 , May 9, 2005
    • 0 Attachment
      Hi Erik, all:

      erikj999 wrote:
      >>Can any language implement any XSD type? If the answer is not, here
      >>there is an interoperability problem.
      >
      > I understand the argument, but respectfully disagree. The purpose of
      > XML Schema in WSDL is to describe the format of an XML message. As
      > long as that format is unambiguously described, interoperability is
      > maintained.
      >
      > WSDL / XML Schema was never intended to prescribe -- or even describe -
      > - a programming model.

      I understand the argument, but respectfully disagree... :) - a little.

      Although it is certainly true that XSD does not describe semantics
      (which is what I'm assuming you mean here by "programming model" - i.e.
      the fact that a hashtable will have unique keys, that the "zipcode" and
      "town" elements in my address should match, etc), that doesn't mean that
      you automatically have "interoperability" until you agree on BOTH data
      format AND semantics. I can send you as many schema-valid messages as I
      want, and just because they're good according to the schema doesn't in
      fact mean that you're going to act the way I want you to act as a result.

      So the question always comes down to semantic agreement across
      agreed-upon data formats. To those detracting the idea that there
      should be an interoperable hashtable (or for that matter recordset!), I
      ask : what the heck is so hard about it? If you'll recall this group
      attempted to get agreement on an XSD map/dictionary/hashtable format
      back a few years ago, and although we had what I think was a perfectly
      fine proposal, it didn't get traction because of (IMHO) non-technical
      reasons. Are the semantics of an STL Map (or whatever the kids are
      calling it nowadays) really that different from a java.util.Map? Heck,
      start with "contract first" even, and define the precise meaning of the
      "interop:Map" type in XSD, *then* allow individual toolkit developers to
      map it to their languages.

      There is, IMHO, no good technical reason that we don't have
      interoperable XML serializations for key->value maps with unique keys
      and simple tabular recordsets. This is, also IMHO, a sad state of
      affairs for programmers who want to get some simple and good stuff done.

      --Glen
    • 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
      • 0 Attachment
        --- 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.