Difference: VOSpace2RFC (7 vs. 8)

VOSpace 2.0 Proposed Recommendation: Request for Comments

This document will act as RFC centre for the IVOA VOSpace 2.0 Proposed Recommendation. The latest version of the specification (02-Dec-2011) can be found at:

• IVOA VOSpace V2.00 Proposed Recommendation

VOSpace is the IVOA interface to distributed storage. This specification presents the first RESTful version of the interface, which is functionally equivalent to the SOAP-based VOSpace 1.15 specification . Note that all prior VOSpace (1.x) clients will not work with this new version of the interface.

Reference Interoperable Implementations

The following are known implementations of VOSpace 2.0:

• CADC - the source code is available at: http://code.google.com/p/opencadc/source/checkout
• VAO - the source code is available via the VAO SVN repository: svn+ssh://usvao-svn@svn.usvao.org/usvao/prototype/vospace/trunk/vospace-2.0/java/merged
• CDS - information available here : http://cds.u-strasbg.fr/resources/doku.php?id=vospace

Implementations Validators

RFC Review Period: 20-May-2012 to 22-Jun-2012

TCG Review Period: TCG_start_date - TCG_end_date

Comments from the IVOA Community during RFC period: 20-May-2012 to 22-Jun-2012

Additional discussion about any of the comments or responses can be conducted on the GWS VOSpace mailing list (vospace@ivoa.net). However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comment by NormanGray

Sect.2 mentions that VOSpace URIs may have fragments, and illustrates how a fragment is literally copied into the retrieval URL from the vos: URL. However this is the only mention of 'fragment' in the document. If the intention is that the VOSpace spec regards the path+query+fragment as opaque, then it would be useful to state this explicitly in Sect.2. Given the potential problems with fragments (see Urbana TCG slides and draft uri-fragments note) it might be useful to do one of the following:

• forbid fragments in VOSpace URIs;
• require that any # characters in a VOSpace URI are encoded when being transformed into a retrieval URL; or
• specify that any fragment is removed as part of the process of transforming the VOSpace URI into the retrieval URI, on the grounds that the fragment will (or at least should) be automatically removed, in passing, by the library which does the HTTP retrieval.

Editorial remark: the HTML version is served with MIME type text/html; charset=UTF-8 (the meta@http-equiv element in the HTML header is ignored), but the content is ISO-8859-1, and there are two soft hyphens (0xad) in the Sect 2 example identifier which appear wrongly in a browser which pays attention to the MIME type.

The example given is: vos://org.astrogrid.cam!vospace/container-6/siap-out-1.vot?foo=bar#baz. I agree that this is ambiguous and could be misinterpreted as identifying a node rather than referring to something internal to a data object. For example., vos://nvo.caltech!vospace/mydata/table1#row3 refers to "row3" within the data resource vos://nvo.caltech!vospace/mydata/table1 (and only resolved by the client when table1 has been retrieved) and should not the identify the data object "row3" in its own right. I will amend the text to correctly describe the behaviour (option 3 above) in the next version. -- MatthewGraham - 21 May 2012

Comments by DaveMorris

Changes to node type

Is there a mechanism where we can change the node type ?

Multi-value properties

"When a Property can take multiple values, e.g., a list of groups which can access a particular resource, these SHALL be represented as a comma-separated list."

Why SHALL and not MAY ?

Unless there is a specific reason for making this explicit, can't we leave it up to the defintion of the property type.

Some property type MAY be comma separated, most probably will, but why do we need to explicitly exclude everything else.

General principle - restrict as little as necessary, and only when we have a specific reason.

Standard properties

If so, is there a queryable registry where we can access the definitions ?

The wording of the specification "The following URIs SHALL be used .." imples that these properties are part of the VOSpace 2.0 standard. In which case, these properties, and their data types, should be defined in an appendix.

Soft hyphens

They show up in some of the XML examples

• http://www.w3.org/2001/XMLSchemainstance
• http://www.w3.org/2001/XMLSchema?instance
• http://www.w3.org/2001/XMLSchema-instance

and in the example identifiers

• vos://nvo.caltech!vospace/myresults/siapout1.vot
• vos://nvo.caltech!vospace/myresults/siap?out?1.vot
• vos://nvo.caltech!vospace/myresults/siap-out-1.vot

Typo property in identifier

• ivo://ivoa.net/vospace/core@btime

should probably be

• ivo://ivoa.net/vospace/core#btime

Typos in compliance matrix

Property definition 13

• 13 A Property has elements:uri, endpoint and param

should probably be

• 13 A Property has elements:uri, value and optional readonly flag

If we have

• 16 Standard capabilities are represented by the specified URIs

then should we also have

• xx Standard properties are represented by the specified URIs

Property definition 26

• 26 A Protocol has elements: uri, endpoint< and param

should probably be

• 26 A Protocol has elements: uri, endpoint and param

-- DaveMorris - 23 May 2012

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->