Definitive version of the VOTable schema for web services

[Matthew Graham]

Hi,
>
> 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.

Yes, the more recent toolkits support this message-level handling and  
it is certainly the approach I prefer. My favourite toolkit for  
calling a web service is XSLT!

The code-binding approach, however, is supposed to be easier for end  
users (astronomers) who know (and want to know) nothing about  
constructing SOAP messages and WSDL. The service returns a VOTable; I  
generate stub code from its WSDL and then have a code representation  
of the VOTable that I can use. I think that we are all agreeing,  
however, that the code toolkits suck. It is, therefore, for the sake  
of the astronomers that we need to make VOTable more usable with the  
toolkits.

> 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,

	Matthew