Hi,
Markus Dolensky wrote:
> Dear All,
>
> Here my comments regarding the VOSpace level 1 doc
> (http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vospace-022-0713.doc):
>
>
> section 3.3
> What's the difference between a 'view' as defined in the document and a MIME type?
>
> Is it worth maintaining a specific list of data formats?
> And even so, how would this be done assuring some coherence?
>
A view defines a data format: the URI of a view is semantically
equivalent to a MIME type but the view structure also provides
information about whether if a particular view is used (to export data)
then the bit pattern of the data is preserved and allows for additional
parameters to be specified that are needed to define the view, e.g. JPEG
compression level.
The view URI is an IVOA identifier which points to resource description
of the data format stored in a registry: the records will most likely be
of xsi:type="vt:Standard" and we are hoping that there will be a central
registry within the IVOA for registration of standards.
> 5.1.3
> Is there a list of (potential) service properties?
>
> Sample B1 in the appendix has a comment saying
> "List the service properties"
> It is, however, actually followed by node properities instead.
>
The getProperties() method needs updating to reflect what is in the
latest version (rc6) of the WSDL: getProperties() now returns:
a list of identifiers for the properties that the service accepts and
understands; a list of identifiers for the properties that the service
provides; and a list of identifiers for all the properties currently
used by nodes within the service.
> 5.2.3
> The paging mechanism is certainly a 'nice to have'. Judging from the list of
> exceptions it is one of the most complicated concepts in this spec. Therefore,
> I'd suggest to provide means to filter node listings instead. Filtering by node
> property value and owner (user/creator), for instance.
>
> Paging is not enough on its own without some prior sorting that brings the
> relevant records to the top. Otherwise it is likely that one has to page all the
> way to the end anyway.
>
> So again, it appears rather complicated but inefficient from a user's
> perspective and one can live without it in level 1.
>
Filtering is a search functionality and we decided that it was one of
the things to save for a later version of VOSpace in order to get v1.0
out of the door as quickly as possible.
> On the other hand it is much harder to life with some other limitations. Evwhen accepting that there are no directories and no operations to change access
> policy for the sake of simplicity I would still argue that some cross VOSpace
> store operations can be supported without bloating the level 1 specs:
>
> A VOSpace that supports pullData{To|From}VOSpace can exploit this functionality
> to implement copyNode and moveNode across stores.
>
VOSpace 1.0 (and indeed it's predecessor VOStore 1.0) has always
conceptually been about flat, unconnected data stores; any notion of
other spaces only comes along later. This keeps the specification and
the implementation simple and clean.
> 5.2.4
> What is the practical purpose of moveNode as is?
>
> According to the specs the data are untouched and it's just a way to create
> another node with some different identifier. Here's what I would expect from an
> operation called moveNode:
>
> - each node has a 'mandatory' name property similar to a filename
> - moveNode sets this property to a new value
> - when a different store is given as a 2nd parameter then it physically copies
> the data using pullDataToVOSpace and deleteNode.
>
It is anticipated that subsequent versions of VOSpace will increase the
functional aspects of many of these methods: however, within the limited
scope of v1.0 (flat unconnected store) some of them seem to do little
but we need to include them to ensure future backwards-compatibility.
moveNode allows the user to assign a new identifier to an existing node
(and also to change any of the node's properties in the process if they
so desire) - the data bytes attached to the node remain unchanged:
copyNode will make another node with a different identifier containing a
copy of the original data bytes. Specifying a different VOSpace as an
additional argument is outside of the scope of v1.0.
> A last general remark:
> Only after going over the verbose XML messages it became apparent to me that
> this spec allows for specialized stores for DB storage and image manipulation.
> It would be interesting to see a bit clearer how to exploit this functionality
> given some scenario rather than being extremely detailed about specific XML
> messages.
>
This has always been in the scheme of things: the idea is that
structured and unstructured data objects are equivalent first-level
entities but obviously understanding the internal structure of a data
object means that you could do things with it. If it supports this type
of operation (and I stress if - this is *not* a mandatory requirement
for a space), a space can offer different views of a structured data
object (the analogy is with views of a db table) so a FITS image could
be viewed as a JPEG or a GIF or a VOTable as a CSV file. One use case is
a SkyNode which has a VOSpace interface: the VOSpace interface can be
used for loading the db that the SkyNode presents: in this case, the
import view is just the import data format but since it is specified,
the space knows how to convert it to a table for the SkyNode to use.
> So, thanks to the authors for their hard work in finding their way to an agreed
> document (which always involves difficult compromises)
We're slowly getting there :-)
Cheers,
Matthew Received on 2006-08-15Z19:54:15