TWiki
>
IVOA Web
>
IvoaGridAndWebServices
>
VOSpace2RFC
(revision 9) (raw view)
Edit
Attach
---++ VOSpace 2.0 Proposed Recommendation: Request for Comments This document will act as *RFC* centre for the [[http://ivoa.net/Documents/VOSpace/20111202/index.html][IVOA VOSpace 2.0 Proposed Recommendation]]. The latest version of the specification (02-Dec-2011) can be found at: * [[http://ivoa.net/Documents/VOSpace/20111202/index.html][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 [[http://www.ivoa.net/Documents/VOSpace/20091007/][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 (If any, indicate here the links to Implementations Validators) ---+++ RFC Review Period: 20-May-2012 to 22-Jun-2012 ---+++ TCG Review Period: TCG_start_date - TCG_end_date <hr/> <hr/> ---++ Comments from the IVOA Community during RFC period: 20-May-2012 to 22-Jun-2012 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 Wiki Name so that 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. 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 TWiki.WikiName * Response (by TWiki.WikiName) ---+++ Comment by IVOA.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. -- IVOA.MatthewGraham - 21 May 2012 ---+++ Comments by IVOA.DaveMorris ---+++++ Changes to node type Lots of places say _"this operation cannot be used to change the node type"_. Is there a mechanism where we can change the node type ? What is the use case for this? It does not make sense in most cases, e.g., changing a ContainerNode to any other type. -- IVOA.MatthewGraham - 25 May 2012 ---+++++ Multi-value properties Section 3.2.1 states _"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. The issue of multiple valued parameters was discussed at a previous Interop and it was decided to represent these as a CSV list. Allowing arbitrary delimiters would mean that you would have to check for this information on a per space basis and it was just simpler to specify the delimiter from the outset. -- IVOA.MatthewGraham - 25 May 2012 When the issue of multiple valued parameters was raised, it was suggested that they __COULD__ be represented as a CSV list. I don't remember it being decided that they __SHOULD__. The delimiter used in a particular property would be defined in the definition of the property type, identified by the property type URI, not on a per space basis. A client only needs to check what the delimiter is IF it intends to do something with the value. Which implies that it already understands what that type of property contains, so it will know what the delimiter is. e.g. _"This property is a comma separated list of intensity values"_ An application that understands the VOSpace property for "a list of intensity values" will know that the list will be comma separated. An application that does not understand the VOSpace property for "a list of intensity values" will just treat the whole thing as a string. If we only allow a specific delimiter, then anyone with existing tab, space, colon or other delimited data will have to re format their data to meet the specification, or they will avoid adding any detail and just define everything as opaque strings. e.g. Java classpath _"This property is a list of files formatted using the Java classpath rules (colon or semi-colon delimited)"_ is more informative than _"This property is an application specific string"_ which is what will happen if we try to force people to use a tool that doesn't fit their data. What do we gain by specifying the delimiter ? Suggested compromise - change the spec to say _"multiple values SHOULD be comma separated, unless the property description defines a specific delimiter"_ -- IVOA.DaveMorris - 28 May 2012 ---+++++ Standard properties Are the standard properties listed in section actually registered somewhere ? 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. As part of the standardization process, the properties will be registered using the StandardsRegExt in the Registry of Registries (i.e., under the ivoa.net namespace). I agree about an appendix and will add it to the next version. -- IVOA.MatthewGraham - 25 May 2012 ---+++++ Soft hyphens There are more than two soft hyphens (0xad) in the text. They appear as <?> symbols in a web browser, but sometimes they are not displayed at all in the PDF version. 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 I'll make the appropriate edits in the next version. -- IVOA.MatthewGraham - 25 May 2012 ---+++++ Typo property in identifier In section 3.2.4 Standard properties, the last property identifier * ivo://ivoa.net/vospace/core@btime should probably be * ivo://ivoa.net/vospace/core#btime I'll make the appropriate edit in the next version. -- IVOA.MatthewGraham - 25 May 2012 ---+++++ Typos in compliance matrix In appendix B: 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 -- IVOA.DaveMorris - 23 May 2012 I'll make the appropriate edits in the next version. -- IVOA.MatthewGraham - 25 May 2012 <hr/> <hr/> <br/> <!-- * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup -->
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r32
|
r11
<
r10
<
r9
<
r8
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r9 - 2012-05-28
-
DaveMorris
IVOA
Log in
or
Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Applications
Data Access Layer
Data Model
Distributed Services & Protocols
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
High Energy
Operations
Radio Astronomy
Solar System
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback