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 Received on 2006-06-14Z13:37:02