VOSpace WSDL

[Dave Morris]

Paul Harrison wrote:

> well I did not see you rigorously using URIs in your comments about  
> http-put etc. above - it is not natural.

Your are right, in an email to a human, it isn't natural.
However, it is useful when you want to be very precise about what you 
are referring to.

<wsdl:definitions
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"

etc .....

> In general I am in favour of  using registry entries to describe 
> something that could possibly be  machine understood and interpreted, 
> so if you can come up with a  registry entry that could describe an 
> arbitrary transport protocol I  would support mandating that the 
> transport name be a URI

Personally, yes, I would like work towards defining an extension of 
VoResource for protocols, web service interfaces and data types that 
would enable us to register them properly.
However, I don't think we are quite ready for that yet.

> otherwise a  simple string name is sufficient.

I'm not arguing for full IVOA registry URIs.
I know that many people have valid objections to them, not least of 
which is how and where they are registered.

Defining them as xsd:anyURI in the WSDL does not mandate the ivo://..... 
syntax.
We could choose to use a URN syntax for the initial set of core 
protocols if you want.

    urn:vospace:protocols:http-1.0-get
    urn:vospace:protocols:http-1.0-put

However, xsd:anyURI leaves it open for us to use the ivo://... syntax to 
point to a resource document describing the details of the protocol if 
we want to.

It would be useful to be able to distinguish between HTTP get and HTTP 
put (a service may accept un-authenticated get but require a signed SOAP 
message for a put).
It would be useful to be able to distinguish between HTTP-1.0-put 
(requires content-size) and HTTP-1.1-put (accepts chunked without 
content-size).

I would need a way of registering the ability to receive chunked data as 
a specific capability in a VOSpace service registration.
It would make sense to use the same URIs or URNs for registering 
protocol capabilities in the service registration document and the 
protocol selection in the SOAP messages.

> I think that mandating that http be a supported protocol 

A data center with a large collection of public images would want to use 
plain http get, and would probably not want to implement DIME or MTOM.
A database service that allowed users to upload data directly into their 
database would probably not accept un-authenticated http-put, and would 
require a signed SOAP message with the data in a DIME or MTOM attachment.

> (and defining what exactly we mean by that) would not be too 
> burdensome on implementations.

A reference to http://www.w3.org/Protocols/rfc2616/rfc2616.html would work.
However, based on our experience, a standard servlet in Apache Tomcat on 
JDK 1.4.x does not support chunked data properly.

------------------

Arguing over the details of HTTP-put is a side issue.
I would like to make the specification open enough so that we can 
define, describe, and use, a new transport protocol (srb://?) without 
having to change the VOSpace specification.

An initial list of core protocols is a good idea.
I'm not convinced that they should be mandatory.

We do need a precise way of referring to them, not just the common name 
e.g. 'http', but something that can distinguish between versions and 
details.
URN style names if you want

    urn:vospace:protocols:http-1.0-get
    urn:vospace:protocols:http-1.0-put

    urn:vospace:protocols:http-1.1-get
    urn:vospace:protocols:http-1.1-put (implies full implementation of 
the spec. including chunked data)

Or, URI/URLs that point to something that describes the details of what 
each one means.

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
    or
    ivo://org.astrogrid.vospace/protocols/http-put-chunked

Defining the parameter as xsd:anyURI in the WSDL is a start, then we can 
argu^^ discuss which ones go in the core list, and which if any are 
mandatory.

Dave