Definitive version of the VOTable schema for web services

[Ray Plante]

Hey Gang,

If I might jump in here...IMHO, one deficiency of these code-binding 
toolkits is that they are very much oriented around an RPC view of the 
remote call.  However, when we send VOTable (or VOResource) what we need 
is a document-view of a remote call.  That is, we send a document as input 
and we get back a document as output.  (I believe this is the semantic 
idea behind "doc-literal", which most of our services use.)

In a document approach, what we need from the toolkit is to be able to 
pass in our XML document in some form (e.g. as a DOM or as a raw XML 
stream) and get out the XML document back (sans SOAP envelope).  (Or have 
an RPC approach to input and a document view of the output.)  This way you 
still can have the typing benefits from the WSDL.  A document-based view 
is better for VOTable and VOResource because we have *easier* ways 
creating and ingesting the content than the thoroughly laborious, 
auto-generated class interfaces.

Axis actually does give you this:  you can get the contents of SOAP 
responses as an array of DOM Elements.  At that point, you can use any 
number of generic XML tools on the data, including (often) a custom 
parser.  This capability of Axis is not as flexible as I would like; 
however, I suspect that it's not often used because developers are not 
really aware of this.  Tutorials tend to push the code-binding approach.

I'm less aware of where other toolkits fall.  (.Net has this capability, 
too.)  I was once a big fan of code-binders, but now I'd rather avoid 
them.  Nevertheless, other people like them and use them.

cheers,
Ray