VOSpace 2.1 issues

[Dave Morris]

Hi Matthew,

On 2014-09-16 18:15, Matthew Graham wrote:
> Hi Dave,
> 
> So how does a user discover what capabilities are available on
> particular nodes? The spec says: "The capabilities list for the Node
> MAY not be filled in until some data has been imported into the Node."

I agree the spec could be worded a bit better.
How about :

"The capabilities list for a Node MAY depend on the data type and 
content of the data imported into the Node. As a result, the service MAY 
update the list of capabilities offered for a Node following the import 
of data into the Node."

> so the user has no idea which of the capabilities offered by the
> server may be employed on the node until they try it with putting data
> in?

The list of capabilities for a Node are like the list of 'OpenWith' 
options on the right-click menu of a desktop file system.

Offering an 'Unpack contents' capability makes sense if the Node 
contains a zip archive, but it does not make sense if the Node contains 
a Word document.

Offering a 'Convert to PDF' capability does make sense if the Node 
contains a document, but it does not make sense if the Node contains a 
zip archive.

Neither of them make sense if the Node contains JPEG image or is an 
empty ContainerNode.

The service MAY offer a 'import into database' capability if the Node 
contains a VOTable, but it may decide not to offer that capability if 
the VOTable contents are not valid.

There MAY be some capabilities that make sense to offer for an empty 
DataNode.

> This also does not allow for the user to indicate that they do not
> want the capability offered until after it is applied automatically by
> the server. This could be wasteful CPU cycles on the server side then.

Like the list of 'OpenWith' options on the right-click menu of a desktop 
file system, controlling which capabilities are offered on which types 
of nodes is probably more of a service admin function rather than an end 
user function ?

Are our users really going to be upset if a service offers them the 
option of converting their document into a PDF ?

Deciding which capabilities to offer on which nodes is an implementation 
issue, but offering the capability is a few extra XML elements in the 
response.

> However, we are agreeing that the VOSpace spec needs to specify a
> standard way for a user to be able to control the capabilities on a
> node. The question is whether to make this explicit with new methods:
> attach/detachCapability or implicit through the use of standardized
> parameters on a capability: (set Node urn:enableCapability=True, etc.)

Nope, sorry.
We do not need to add anything to the VOSpace specification.

All of the examples can be covered simply by using some new properties 
and capabilities, which do not need to be part of an IVOA standard.

IF these new capabilities prove to be useful/popular, then they can be 
described in an IVOA note and given IVOA registry URIs.

> Not certain about the metacapability capability though - I just can
> see the reaction that would provoke it some quarters.

This is exactly the kind of thing the Node capabilities were designed to 
handle.

The flexibility of the Node capabilities enables different service 
providers to experiment with different forms of 'ManageCapabilities' and 
'ManagePermissions' capabilities and lots of 'NotInventedYet' and 
'InterestingIdea' capabilities.

Then, IF we find some that work well and are easy to use, we can adopt 
them into the IVOA standards by describing them in an IVOA note and 
giving them IVOA registry URIs.

----

Adding new capabilities is like adding a new message to SAMP.

It is just a new URI.

If a client knows what the URI means, they can use it.

If a client does not know what the URI means, they can ignore it.

If a person wants to learn what a new URI means, they can put it in a 
web browser and hopefully find something informative.

----

Hope this helps,
Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------