VOSpace service specification: Request for Comments

This document will act as RFC centre for the VOSpace service specification Proposed Recommendation V1.01. There is also an accompanying WSDL and schema.

Review period: 23 July 2007 - 20 August 2007

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussions about any of the comments or responses should be conducted on the VOSpace mailing list, vospace@ivoa.net.

Implementation details

Three implementations of VOSpace 1.0 have been produced:

• Caltech
  • Endpoint: http://nvo.caltech.edu:8080/vospace/VOSpaceServiceImpl
  • VOSpace apache: vos://nvo.caltech!vospace/
  • Secure: yes

• ESO
  • Endpoint: http://vops1.hq.eso.org:8080/vospace/services/VOSpacePort
  • VOSpace apache: vos://org.eso!vospacetest/
  • Secure : yes

• Astrogrid
  • Endpoint:
  • VOSpace apache:
  • Secure:

Although not fully documented, the Caltech VOSpace implements all features of the VOSpace 1.0 specification including StructuredDataNodes and the ability to request different views.

Two VOSpace clients have also been produced at Caltech - one to talk to secure VOSpace services using digital signatures (WS-Security) and one to talk to unsecure services. These clients utilize a different underlying web service infrastructure to the one that the Caltech VOSpace implementation is based on (Apache Axis 1.2.1 Final vs. XFire 1.2.2).

The secure client has successfully negotiated data storage at the ESO VOSpace, including a third party data transfer into the VOSpace from a cone search service. This demonstrates sufficient interoperability of the implementations.

Comments from the Community

• First sample comment (by MarSierra): ...
  • Response (by authorname): ...

Comments from MarkTaylor

• Description members:
  • The Description members of various items are characterised "A text block describing ...". For implementors and users of this standard it would be helpful if a bit more detail about the intended format of this text block could be supplied, for instance should it be a short summary or a detailed description and should newlines and spaces in it be honoured or are multiple whitespaces insignificant. A mismatch in interpretation of this sort of thing between metadata supplier and data consumer can lead to ugly/unreadable presentation of such items to the user. I understand that the details of how various descriptions are to be written is somewhat dependent on schemas external to this document yet to be written, so possibly this can't be clarified at this stage.

• getProperties operation
  • accepts return value is described as "A list of identifiers that the service accepts and understands". What does "understands" mean here?
  • contains return value: Is it wise to require this as a return? If the VOSpace service is implemented in such a way that it can accept arbitrary properties to be associated with each node, then I'd have thought this could be rather a large list and expensive to determine.

• listNodes operation
  • Either I've misunderstood how the wildcarding works or the list of matched examples is wrong. To me it looks like *.txt ought to match .txt and frog.txt but not .txtinfo or frog.txtinfo.

• Data model UML diagram:
  • s/propetty/property in Node box

• setNode operation, Faults section:
  • "if the requests attempts" -> "if the request attempts"

• pullDataFromVoSpace operation, Notes section:
  • "The any endpoint URLs..." rephrase.

• pushDataFromVoSpace operation, Faults section:
  • Delete Bullet item 7 (partial repetition of bullet item 8)

-- MarkTaylor - 01 Aug 2007