VOSpace WSDL

[Dave Morris]

Paul Harrison wrote:

> I am also against the use of URIs in many of these cases .... for 
> things like the transport  protocol it is far better to use the common 
> well-known name for the  protocol e.g. ftp rather than introducing an 
> indirection layer for  the name via a URI, so that people can 
> immediately use their domain  knowledge to recognise what is being 
> referred to.

The 'http put' transfer is a good example of why the specification uses 
URI rather than just the 'well-known names' for protocols.
There are several ways to send data using HTTP.
The two main forms are :

    http-put
    http-post

Based on our experience with VOStore and AstroGrid MySpace, we also need 
to distinguish between services that can accept chunked data in a 
http-put call.
A standard http-put call sends the data size in the header, which means 
that the client has to buffer all of the content to calculate the size 
before it sends the data.
Sending data using http-put in chunked mode does not require the data 
size in the header field.
However, not all server implementations can accept chunked data (even 
though they claim to implement HTTP-1.1), so we need to be able to 
distinguish between services that can accept chunked data, which gives 
us three variants of http-put.

    http-post
    http-put
    http-put (chunked)

We may also need to distinguish between services that accept http-put 
with data compression (zip, gzip etc.) and different forms of 
authentication.
If we used the 'well know name' for protocols, all of the above could be 
covered by 'http'. 

DIME and MTOM attachments also have two main variants.
The data can be attached to the original VOSpace message, which would 
not require a separate URL to send the data to.

    dime-put (this message)

Or, it could be sent in a separate SOAP message, which would require 
information about the target service, the endpoint URL and some form of 
identifier.

    dime-put (other) +wsdl, endpoint, ident

There may be other forms which 3rd party developers want to add; all 
based on the core http protocol, but using different data handling and 
authentication methods.
The reason for identifying these using a URI, particularly an ivo://... 
registry URI is that it gives us somewhere to put a description of the 
protocol.

For example :
http://galahad.star.le.ac.uk:8080/astrogrid-registry/viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%2Fprotocols%2Fhttp-put
http://galahad.star.le.ac.uk:8080/astrogrid-registry/viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%2Fprotocols%2Fhttp-put-chunked

I appreciate that using registry resources to describe the protocols is 
contentious, which is why the specification defines protocol and format 
parameters as a URI and not an IVOA registry URI.
If people don't want to use IVOA registry URIs, then we could use the 
http URL of the protocol specification.
If someone wants to use a different form of DIME web service to receive 
data, then the URI could point to the service specification or WSDL.
The point is that in much the same way as people use namespace URIs in 
XML schema, the protocol URI is not just a text string, it can be used 
to point to something that describes the specific protocol.

This was discussed both before and during the Canada meeting, and no 
major objections were raised at the time.
Which is why the v0.21 document specifies protocol and format as URI, 
with examples of IVOA registry URIs.
If you want to change this to an enumeration of strings, then we need to 
go back and modify the document.

> One compromise could be to have the enumerated lists published in a  
> different namespace, but not use them as types to restrict the values  
> in the formal WSDL. These enumerations could then be updated for a  
> V1.1 release without directly affecting the WSDL contract

I agree, an initial list of the core protocols and formats could be useful.
However, the values should be URIs, and the documentation should make it 
clear that this is not a closed or mandatory list.
3rd party developers should be required to implement all of the 
protocols in the list.
3rd party developers should be free to add additional transport 
protocols and data formats without requiring a change to the specification.

Which protocols actually go in the initial list is open for discussion ....

Dave