| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | VOSpace home page | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | VOSpace home page | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Discussion of the VOSpace 1.0 specification DocumentThe VOSpace-1.0 specification has been completed and submitted as an IVOA working draft. The final versions are available here : | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is a discussion page for the VOSpace-1.0 service specification document. This is somewhere where we can post proposals and to enable interested parties to discuss the different versions. For each version there is a Change request section - please add to this and vote on other suggestions
Version 0.22 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This document was produced as a result of the discussions that have occured since the Victoria Interop meeting.
Change RequestsAllow typing of propertiesThe current scheme is limited to key-value pairs where the value is interpreted as a string. A problem with this that some key-values pairs might be intended to represent other datatypes, e.g. a date or a float, and without this typing information, it is impossible to check the validity of the value. It is always possible for a client to add this information with an xsi:type attribute, e.g. <property uri="ivo://net.ivoa/properties/date" xsi:type="xs:dateTime">2006-11-22T18:50:03Z</property> but this might not be interpreted properly by the browser. However, if we actually add a type attribute then we can cover this: <property uri="ivo://net.ivoa/properties/date" type="xs:dateTime">2006-11-22T18:50:03Z</property>. The attribute is optional and non-inclusion implies that the datatype is string. The value of the attribute can either be an XML datatype or a reference to an XML schema that describes the data structure thus allowing for more complicated properties such as:<property uri="ivo://net.ivoa/properties/color" type="myschema.xsd"> <color> <red>123</red> <blue>234</blue> <green>89</green> </color> </property> Votes
Rename views to formatsThis needs to be renamed to what it actually is, i.e. format(s), since the current name is universally confusing.Votes
Decoupled data serversUnder the current scheme, it is assumed that there is some communication channel between the VOSpace and a data server, e.g. a gridftp server, so that when a pushTo or pullFrom is completed, the data server can notify the VOSpace service that the transfer has completed. This sort of activity is particularly necessary when the endpoint is a logical one, e.g. a one-time-use URL. This design is fine for the cases where we have implemented the data servers ourselves or have access to the source code so that we can add the callback; however, what happens when you are dealing with an off-the-shelf data server where this is not the case or non-trivial, e.g. the Globus gridftp server. One solution is to have the client notify the VOSpace when the transaction is complete (since this really is only a problem for the asynchronous services) so pushToVoSpace would become:
Votes
copyNode and moveNode to operate across storesSee message for rationale of above itemized list:
Votes
Make the destination of CopyNode and MoveNode a simple uriThe advantage is it simplifies the standard doc (so many restrictions on node) and is much easier for client to use... as does not have to create a node object - simply create a uri for the destination.Votes
Re-assess what metadata should be returned with various faultsSome faults need to return metadata beyond simply their type to convery meaningful information about exactly what has gone wrong. e.g. for a setDataNodeProperties call could specify several read-only properties amongst a larger number of properties, and the client would not know which were the properties in error without a list being returned in the fault.Votes
Version 0.21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This document was produced as a result of the discussions that occured at the Victoria Interop meeting.
ChangesVOspace10Spec21ArchiveChanges for later versions of VOSpaceConsider adding an optional wildcard matching identifier to parameters for ListNodesThis would allow the client to specifly a subset of the VOSpace to be listed - in effect the behaviour would be similar to the "ls" command in unix, with typical simle shell wildcard semantics. Reason for change: improved efficiency - if ListNodes always has to list the whole VOSpace then it is a pretty blunt instrument, especially as the number of data objects in the space increases.Use CaseSuppose that there is a 1.0 VOSpace containing 5000 data items and a workflow step is writing results into the VOSpace using a common prefix. The next step in the workflow wants to process all of the files produced, but only knows the prefix - without wild card matching the whole of the VOSpace needs to be listed to find the files. -- PaulHarrison 19 Jun 2006Votes
Add a FindNodes operationThis operation would allow a simple search on the VOSpace - the level of functionality would be similar to the unix "find" command. |