remarks about VOSpace level 1

Dear All,

Here my comments regarding the VOSpace level 1 doc (http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vospace-022-0713.doc):

section 3.3
What's the difference between a 'view' as defined in the document and a MIME type?

Is it worth maintaining a specific list of data formats? And even so, how would this be done assuring some coherence?

5.1.3
Is there a list of (potential) service properties?

Sample B1 in the appendix has a comment saying "List the service properties"
It is, however, actually followed by node properities instead.

5.2.3
The paging mechanism is certainly a 'nice to have'. Judging from the list of exceptions it is one of the most complicated concepts in this spec. Therefore, I'd suggest to provide means to filter node listings instead. Filtering by node property value and owner (user/creator), for instance.

Paging is not enough on its own without some prior sorting that brings the relevant records to the top. Otherwise it is likely that one has to page all the way to the end anyway.

So again, it appears rather complicated but inefficient from a user's perspective and one can live without it in level 1.

On the other hand it is much harder to life with some other limitations. Even when accepting that there are no directories and no operations to change access policy for the sake of simplicity I would still argue that some cross VOSpace store operations can be supported without bloating the level 1 specs:

A VOSpace that supports pullData{To|From}VOSpace can exploit this functionality to implement copyNode and moveNode across stores.

5.2.4
What is the practical purpose of moveNode as is?

According to the specs the data are untouched and it's just a way to create another node with some different identifier. Here's what I would expect from an operation called moveNode:

• each node has a 'mandatory' name property similar to a filename
• moveNode sets this property to a new value
• when a different store is given as a 2nd parameter then it physically copies the data using pullDataToVOSpace and deleteNode.

A last general remark:
Only after going over the verbose XML messages it became apparent to me that this spec allows for specialized stores for DB storage and image manipulation. It would be interesting to see a bit clearer how to exploit this functionality given some scenario rather than being extremely detailed about specific XML messages.

So, thanks to the authors for their hard work in finding their way to an agreed document (which always involves difficult compromises).

• Markus