International Virtual Observatory Alliance

Difference: VOSpace10Spec (3 vs. 4)

Revision 42006-06-16 - PaulHarrison

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

vospace-0.21.doc

This document was produced as a result of the discussions that occured at the Victoria Interop meeting.

Change Requests

Added:

>
>

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.

Votes

name	vote	comment
PaulHarrison	+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

Votes

name	vote	comment
PaulHarrison	+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

Deleted:

<
<

-- PaulHarrison

I agree a list of the common properties would be useful.

How about Define each of the common (not mandatory) properties in an annex of the main specification.

Then, we post a separate change request for each property, including details of exactly what it means and how it is represented.

-- DaveMorris - 16 Jun 2006

Votes

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

Changed:

<
<

-- PaulHarrison

>
>

Votes

Added:

>
>

name	vote	comment
PaulHarrison	+1

Deleted:

<
<

I agree we need to clarify this. However, MIME type does not describe what we need.

Changed:

<
<

Like property and protocol, we should add definitions of the common VO formats as an annex to the specification.

>
>

Change "exception" to "fault"

Added:

>
>

The document uses the term exception for the "faults" rather than "fault"

Votes

name	vote	comment
PaulHarrison	+1

Changed:

<
<

-- DaveMorris - 16 Jun 2006

>
>

Consider adding an optional identifier list to the parameters for ListNodes

Added:

>
>

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.

Votes

name	vote	comment
PaulHarrison	+1

Added:

>
>

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.

Votes

name	vote	comment
PaulHarrison	+1

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r35 < r34 < r33 < r32 | More topic actions...