... Whilst moving to document based services from encoded was indeed a step backwards in terms of interoperability between code based tools, it s been a giantMessage 1 of 62 , May 9, 2005View Source
> People say the best way to build interoperable web services is focusWhilst moving to document based services from encoded was indeed a step
> on the XML documents. I'm increasingly thinking that's the only way to
> do things. Alas, what that means in most languages is you treat your
> SOAP packets like XML documents and slog through them with DOM or the
> like. I fear that in many languages you're better off without the
> fancy SOAP/WSDL toolkits entirely.
backwards in terms of interoperability between code based tools, it's
been a giant leap forward for those of us who have to unite the code and
document universes. Adding decoration such as soapArray attributes into
messages generatded using XSLT just so the likes of .NET would accept
them was no fun.
So I'll take the oportunity to once again shamelessly plug the up and coming
W3C Workshop on Schema User Experiences* where basically this topic is
going to be the subject of two days discussion.
-- It's our best chance to encourage the W3C to better help
us in our attempts to use XML Schema to describe Web service messages,
... 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, 2005View Source--- In firstname.lastname@example.org, Simon Fell <ws@z...> wrote:
> >I've never personally had a dateTime problem, which in retrospect1. .net1.1 time assumes that times are in local tz, so if your service
> >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).
is working w/ GMT zones then you only get interop problems in the GMT
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.