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

Nice job on this document; it has the proper level of specificity for a service specfication.

• I think we need to treat these specifications like any other peer-review publication; thus, it is appropriate to include acknowledgements to our funders. For contributions by Matthew, I suggest the boiler-plate that I provided in my SSO comments.

• There's an additional bit of boiler plate that I like to see in these documents that define abbreviations that we insiders are familiar with. Again, you can consider my suggested text for a preface setion called "Definitions".

• I would strongly encourage numbering the sections of the document in the style "1.4.2". This allows one to refer to a specific defintition or requirement with a little more specificity (e.g. "This service not compliant because it does not ... as required by the the VOSpace specification, section 2.3.1").

• Introduction: This document would greatly benefit from a subsection in the introduction (e.g. "Typical Use of a VOSpace Service") that steps us through an example of putting and retrieve data to/from a VOSpace, showing sample SOAP messages. This should introduce the major concepts, mapping them to concepts we understand (e.g. Node represents a file) without necessarily defining them generally. As it is now, it provides a bottom up description of the service--which is what you want in a spec; however, the reader doesn't discover how it all fits together until the end. (I felt like I was reading mystery novel, flipping the pages back to see how I was supposed to understand the clues revealed earlier. )

• Introduction: Along the same theme, it would also be good to end the introduction with another subsection (e.g. "Document Roadmap") that describes how the rest of the document is laid out. With this road map in mind, the reader will understand how the parts will be fitting together as he/she is reading them.

• Nodes and node types: please repeat the definition of VOSpace here. (It's given in the Abstract; however, an abstract is usually a summary of the contents of the document.) Then think carefully about how the term is being used in the section and make sure you are being consistant. I suspect that some clarification of the definition will be needed, but I'm not sure.

• Nodes and node types: please provide a clearer semantic definition of node before launching into a definition of the types of nodes. It should be clear (perhaps with additional explanation) before talking about the types that a data file (something we all understand) is represented as a node.

• Nodes and node types: paragraph after first bulleted list of types needs to end in a period.

• Property identifiers: I strongly recommend that when IVOA identifiers are used to identify properties (as well as views and protocols) that they use the form, ivo://auth/blah#property-name. As the authors know, every IVOA Identifier must resolve to a separate resource description. By using the pound delimiter, all of the method names can be defined within a single resource description. The latest internal WD version of VOStandard (v0.2) supports this type of definition. We can push this to a released WD to help support VOSpace.

• Views: In keeping with the above recommendation, I suggest that standard views be defined with one of the following forms:
  • ivo://ivoa.net/vospace#view-any, to include the definition in the standard that describes the VOSpace standard as a whole, or
  • ivo://ivoa.net/vospace/views#any, to have a resource specifically for the definition of views.
  I prefer the first alternative, because it consolidates all the VOSpace information in one resource document, which will make maintanence simpler and make the registry seem less cluttered.

• View descriptions, last sentence: The Registry WG can provide the clarity needed to replace this sentence with a more definitive statement on the timescale of the approval process for this document. In particular, the RWG should:
  • add support for DisplayName in the VOStandard schema (if desired)
  • release updated schema to WD status

• Protocol identifiers: change form of IVO-ids to form using pound (#).

• Local NFS transfers: change form of IVO-ids to form using pound (#).

• Web service operations: it would be helpful to be a bit more explicit that when you say "description of the Node " that you mean a structured in terms of the model specified on p. 9. This can either be done by saying something like "(type: Node )" or with an explicit page or section reference to where Node is defined.

• pushToVoSpace, Returns: it would be helpful to state here that the endpoint refers to the destination URL (yes?)

• pullToVoSpace, Parameters: it would be helpful to state here that the endpoint refers to the source URL (yes?). (And so on with other operations.)

• Can we include/reference the official standard WSDL?

• Can we define the Registry VOResource extension for registering VOSpaces? Is this coming?

-- RayPlante - 20 Aug 2007