(r9) VOSpace10Spec < IVOA

IVOA Web>IvoaGridAndWebServices>VOSpace10Spec (revision 9) (raw view)~~EditAttach~~
---+ 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

---
%TOC%
---
---++ Version 0.21
   * [[http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vospace-0.21.doc][vospace-0.21.doc]]

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.

-- IVOA.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.

-- IVOA.DaveMorris - 16 Jun 2006

I think that where VOSpace is acting as a http server then it would be good to mandate http-1.1 compliance - it does fix issues with 1.0 and afterall it is a 7 year old specification now....

As far as a compliance statement goes - how about 

(http-1.1-get or https-1.1-get) and (http-1.1-put or https-1.1-put)

-- IVOA.PaulHarrison - 19 Jun 2006 
---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | -1 ||

---+++ 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
   * ftp
   * gridftp

-- IVOA.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.
<verbatim>
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
</verbatim>

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | +1 ||

---+++ 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

-- IVOA.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.
<verbatim>
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]
</verbatim>

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.

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | +1 ||

---+++ 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
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||


---+++ Change "exception" to "fault"
The document uses the term exception for the "faults" rather than "fault"
-- IVOA.PaulHarrison

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | -1 | I can't see a significant benefit from changing this|


---+++ Consider adding an optional wildcard matching identifier to 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, with typical simle shell wildcard semantics. 

Reason for change: improved efficiency - if ListNodes always has to list the _whole_ VOSpace then it is a pretty blunt instrument, especially as the number of data objects in the space increases.

---++++ Use Case
Suppose that there is a 1.0 VOSpace containing 5000 data items and a workflow step is writing results into the VOSpace using a common prefix. The next step in the workflow wants to process all of the files produced, but only knows the prefix - without wild card matching the whole of the VOSpace needs to be listed to find the files.

-- IVOA.PaulHarrison 19 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 |proposer|

---+++ 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. 

Reason for change: improved efficiency - if ListNodes always has to list the _whole_ VOSpace then it is a pretty blunt instrument, especially as the number of data objects in the space increases.

---++++ Use Case
Suppose that there is a 1.0 VOSpace containing 5000 data items and a client is currently interacting with a V2.0 VOSpace that has links to a small subset (e.g. 100 data items) - the client needs to make 100 getNodeProperties SOAP calls to the V1.0 space to get the latest metadata about the data objects - with an optional identifier list it can make one call to ListNodes.

-- IVOA.PaulHarrison 19 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 |proposer|
| IVOA.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.
-- IVOA.PaulHarrison

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 |the benefit is improved clarity - in addition there is the slightly irritating issue (see below) that you cannot take the property list from the "get" and use it in the "set" because of read-only properties|
| IVOA.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...
-- IVOA.PaulHarrison

Agree, need to make this clearer.
   * Null value deletes property.
   * Operation is union not replace.
   * Server throws PermissionDenined for read-only properties.
      * what if only one of the list of properties is read-only? - need to signal which are the bad properties in the exception.

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | +1 ||

---+++ 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"
-- IVOA.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.

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 ||
| IVOA.DaveMorris | +1 ||


<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r9 - 2006-06-19 - PaulHarrison
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema