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.
    • One would hope that common sense prevails and that the length of the Description is sufficient to provide a concise overview and any specific usage details where necessary. As to formatting details, I agree that some sort of convention would be nice but we do not specify such constraints with other descriptive text elsewhere in the VO (c.f. the element in VOResource) so maybe this is a wider issue that needs to be addressed. (MatthewGraham)

• getProperties operation
  • accepts return value is described as "A list of identifiers that the service accepts and understands". What does "understands" mean here?
    • The intent here is that there might be metadata (properties) that is implementation dependent but can be used by the user to control operational aspects and this is what "understands" refers to. An example is access control: a VOSpace implementation might allow individual users to control the permissions on data objects via a property called something like "permissions". If the VOSpace receives a data object with this property then it understands what this property refers to and can deal with it accordingly. I agree that clarification is required in the spec and we will address this in the next revision. (MatthewGraham)
  • 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.
    • Firstly, any VOSpace can accept arbitrary properties - this is not implementation dependent. Some properties might be implementation controls which is what accepts returns (see comment above on this). Now it need not necessarily be expensive to determine contains but this is an implementation detail. Given that arbitrary properties can be used, there should be an operation that returns a list of which properties are being used in a particular space - this will aid with queries across federated VOSpaces, e.g. I want to find all data objects with this property. It is inefficient to do a full listing of each space when one can first of all just get a list of all the properties used within that space and determine whether it should be used further or can be passed over. (MatthewGraham)

• 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.
  • I agree that *.txt should only return .txt and frog.txt and will remedy this in the next revision of the document. (MatthewGraham)

• Data model UML diagram:
  • s/propetty/property in Node box
    • I will remedy this in the next revision (MatthewGraham)

• setNode operation, Faults section:
  • "if the requests attempts" -> "if the request attempts"
    • I will remedy this in the next revision (MatthewGraham)

• pullDataFromVoSpace operation, Notes section:
  • "The any endpoint URLs..." rephrase.
    • I will remedy this in the next revision (MatthewGraham)

• pushDataFromVoSpace operation, Faults section:
  • Delete Bullet item 7 (partial repetition of bullet item 8)
    • I will remedy this in the next revision (MatthewGraham)

-- MarkTaylor - 01 Aug 2007