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 Received on 2006-06-14Z16:32:05