| |
| META TOPICPARENT |
name="IvoaGridAndWebServices" |
Discussion of the VOSpace 1.0 specification Document
This is a discussion page for the VOSpace-1.0 service specification document.
This is somewhere where we can post proposals and to enable interested parties to discuss the different versions.
For each version there is a Change request section - please add to this and vote on other suggestions
- +1 if you agree
- -1 if you disagree
- 0 if you have no particular preference
Version 0.21
This document was produced as a result of the discussions that occured at the Victoria Interop meeting.
Change Requests
Mandate and define at least one transport protocol
without this a compliant VOSpace will not be able to transfer data to another compliant VOSpace.
I recommend http be mandatory. |
|
>
> |
-- PaulHarrison
- Which version, http-1.0 or http-1.1 ?
- Which methods http-get, http-put or both ?
- For a space that stores public images, then http-1.1-get makes sense.
- For a space that allows upload to sensitive database tables, then http-1.x-put does not have sufficient authentication.
-- DaveMorris - 16 Jun 2006 |
| | Votes
|
|
>
> |
|
| |
Specify as optional a small list of well known transport protocols
so that at least implementations will do the same thing for common protocols - this list to include |
|
>
> |
-- PaulHarrison
Agree with the list of common protocols.
Defined in a annex to the main specification, including a standard URI and details of the protocol specification (can be just short note and a reference to the external specification).
e.g.
HTTP 1.1 get
URI
ivo://....vospace/protocols/http-1.1-get
Description :
Get data using the HTTP-1.1 GET method as defined in RFC2616.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
-- DaveMorris - 16 Jun 2006 |
| | Votes
|
|
>
> |
|
| |
Specify the key names and meanings for a small group of "essential" property keys
The minimum set which I would say we need mandatory names are
- vos.Owner
- vos.ModificationDate
- vos.Size
- vos.MimeType
|
|
>
> | -- PaulHarrison
Agree with the list of common properties.
Defined in a annex to the main specification, including a standard URI and details of what each property means and how it is represented.
e.g.
Data created date
KEY
vos.data.created.date
Description :
A read-only property generated by the server.
Indicating when the data contents were originally created.
Formatted as a ISO 8601 date-time [yyyy-mm-ddTHH:MM:SS.SSS]
----
Data modified date
KEY
vos.data.modified.date
Description :
A read-only property generated by the server.
Indicating when the data contents were last modified.
Formatted as a ISO 8601 date-time [yyyy-mm-ddTHH:MM:SS.SSS]
Note - As VOSpace-1.0 does not support append, the only way the created and modified dates will be different is if the server modifies the data underneath.
-- DaveMorris - 16 Jun 2006 |
| | Votes
|
|
>
> |
|
| |
Clarify the use of the Format parameter in some calls
I believe that the original intention of Format was to specify a possible transformation of the data (mainly on export of table data from RDBMS based stores). In the current version of the document it reads as if this parameter is merely a description of the data - in which case mime-type suffices. In addition I am not sure if this parameter has any meaning for import operations.
Votes
Change "exception" to "fault"
The document uses the term exception for the "faults" rather than "fault" |
|
>
> | -- PaulHarrison |
| | Votes
|
|
>
> |
| DaveMorris |
-1 |
I can't see a significant benefit from changing this |
|
| |
Consider adding an optional identifier list to the parameters for ListNodes
This would allow the client to specifly a subset of the VOSpace to be listed - in effect the behaviour would be similar to the "ls" command in unix. |
|
>
> | -- PaulHarrison |
| |
Votes
|
|
>
> |
| DaveMorris |
-1 |
I can't see a significant benefit from changing this |
|
| |
Reconsider getNodeProperties and setNodeProperties
the naming of these operations makes them appear as a pair, where in fact they are not - you get a Node out of the getNodeProperties and have to put a PropertyPairList into the setNodeProperties - If the change to ListNodes were made as above, then getNodeProperties would be redundant anyway. |
|
>
> | -- PaulHarrison |
| | Votes
|
|
>
> |
| DaveMorris |
-1 |
I can't see a significant benefit from changing this |
|
| |
Semantics not clear for setNodeProperties
It is not clear
- how to delete a property - does a null value of the property pair denote this?
- does the whole set of node properties given as an argument replace the whole set for the node, or is a union operation performed.
- interaction with the "read-only" properties in these scenarios...
|
|
>
> | -- PaulHarrison
Agree, need to make this clearer.
- Null value deletes property.
- Operation is union not replace.
- Server throws PermissionDenined for read-only properties.
-- DaveMorris - 16 Jun 2006 |
| | Votes
|
|
>
> |
|
| |
Change names of parameters for moveNode and copyNode
Target is a confusing name for the "source" part of a move operation it sounds more like "destination" - recommend use "source" and "destination" |
|
>
> | -- PaulHarrison
Yep, source and destination are probably better. As long as we make it clear that these are internal locations, not references to external locations.
-- DaveMorris - 16 Jun 2006 |
| | Votes
|
|
>
> |
|
| |
<--
--> |
