> Of course, most hand coded XML document systems do end up
> coding to some wierd model that is doable but not always
> pleasant, and sometimes people like Rich have no choice but
> to work with them.
I agree that that is the case today. But I wonder what would happen if we
diverted our collective effort from O/X mapping and focused on making easier
to use XML APIs? I think we could solve a lot of the problem.
> What is important about starting off with the WSDL is that
> you can build up some model of what the person at the far end
> is going to get; start with the objects and back into an
> interface, and you have an interface that may change with
> every point release of your SOAP stack.
It is certainly the case that if you don't start with WSDL/XSD and you leave
generation of metadata to your toolkit you will end up in trouble. Since
WSDL/XSD is key to plugging services together, treating it as a side-effect
of implementation doesn't make any sense.
> Another issue with O/X mapping is that it is too appealing a
> metaphor for end users, but it is the wrong metaphor. Imagine
> I am using my SOAP stack to talk to tim's service, and it
> generates classes that act as proxies to his service.
> Suddenly I am presented with the distributed objects
> metaphor, rather than the reality of
> XML-documents-POSTed-over-HTTP. I start to make assumptions,
> like round trip time of an invocation being something low, or
> that the lifespan of the remote service and that of my local
> proxy are somehow related. Those are assumptions that will
> get me into trouble, yet, if you follow mail lists like
> axis-user, you will see them arising again and again.
This is a very good point.