VOSpace 1.1 changes
dave at ast.cam.ac.uk
Mon May 19 02:20:02 PDT 2008
I would like to request a few changes to the proposed VOSpace 1.1
Most are just small changes to the document or wsdl that should not need
The last two points, regarding inherited properties and the FindNodes
operation may need to be discussed further.
1) Faults in wsdl
Container and Link faults need to be added to the WSDL binding.
Although both the LinkFound and ContainerNotFound faults have been added
to the definition of the wsdl:portType,
The new faults also need to be added to the corresponding operations in
<soap:fault use="literal" name="ContainerNotFoundFault"/>
<soap:fault use="literal" name="LinkFoundFault"/>
Without this, the Axis wsdl2java code generator does not add the
corresponding exceptions to the service methods.
This applies to all of the methods that can throw ContainerNotFoundFault
2.1) Link target
In the document, the text describing the LinkFoundFault describes the
link target as :
".. a node that points to another node."
This implies that the link target should only be used to point to other
VOSpace nodes, and cannot be used to point to other types of resources.
In the XML schema the link target is defined as xsd:anyURI in both the
LinkNodeType and the LinkFoundFault
Can we change the description in the document to allow any URI, with no
restriction on what the link can link point to.
There is a valid science use case for allowing the link to point to any URI.
An easy way to mirror the contents of an existing FTP server within
would be to create a set of link nodes that point to the data in the
This also allows scientists to use LinkNodes with properties
to annotate data that is stored in external servers outside the VO.
2.2) Link target (null)
The document does not say if a LinkNode target may be null or not.
The XML schema for a LinkNode implies that it cannot be null.
<xsd:element name="target" type="xsd:anyURI" minOccurs="1"
However, the XML schema for the LinkFoundFault does allow the target to
<xsd:element name="uri" type="xsd:anyURI" nillable="true"/>
The document should be updated to specify whether the link may be null,
and the two XML schema definitions should be consistent.
3) GetNode and SetNode faults
The list of faults for both GetNode and SetNode method should probably
include ContainerNotFoundFault (in both the document and the wsdl).
A link may occur at any point in a path, so the LinkFoundException needs
to return the URI of the point where the link was encountered.
Given the path
If the link node is at
with a link target of
then the client will need to know that it needs to add the remainder
gamma/delta to the link URI
to create the new URI
In order to enable the client to do this, it needs to know which of the
nodes in the original path caused the exception.
I would like to propose that we change the structure of the
LinkFoundFault to contain two URIs, one for the node where the link was
found, and another for the link target.
Suggested XML schema change :
<xsd:element name="node" type="xsd:anyURI" nillable="false">
The URI of the node where the link was encountered.
<xsd:element name="link" type="xsd:anyURI" nillable="false">
The target URI that the link points to.
6) Inherited properties.
At the moment, I'm not sure that inherited properties are ready to be
There are a number of issues that need to be resolved before we can add
these to the final specification.
First is the issue of how we define a property as being inheritable.
This would have to be done with an external definition of the property,
probably in the registry resource that defines the property.
If not, then we will get inconsistent behavior if one service treats a
particular property and inheritable and another does not.
Second, I think we need to produce some detailed use cases describing
what happens when a node with an inherited property is copied from one
service to another. If I remember correctly, in version 1.0 we said that
if a service does not understand the meaning of a specific property,
then it may treat the property as a simple string value. This could
produce inconsistent behavior if tree of nodes with an inherited
property is copied from a service that does treat a property as
inherited to a service that does not.
Note, I have no objection to the concept of inherited properties, and if
we can address these issues at the meeting then I would be quite happy
for them to be included in the 1.1 specification.
7.1) Optional capability
I would like to request that the FindNodes operation be moved to an
optional part of the specification, defined as a separate capability
from the core VOSpace 1.1 service.
The main reason for requesting this is that up to this point it should
be fairly easy to implement a simple VOSpace service without requiring a
SQL database to store the metadata. Adding the FindNodes operation to
the core service specification makes it much harder to implement a full
VOSpace 1.1 service without using a SQL database.
Making the FindNodes operation an optional capability does not detract
from its usefulness, and I expect that most large scale implementations
will support it. However, we should take care not to exclude smaller
scale implementations who just want to make a small number of simple
files available via a VOSpace service.
If we define the FindNodes operation as a separate capability, a service
registration would list the core VOSpace 1.1 service capability, and a
separate capability for the VOSpace 1.1 FindNodes operation, if the
service supported it.
7.2) Regular expression syntax
The current document specifies a FindNodes match element as containing a
regular expression that is used to match a property value.
However, it does not define which variant of regular expression syntax
should be used.
SQL standard regular expressions use a different syntax to the other
commonly used forms such as Perl and POSIX.
We would need to specify which form of regular expressions should be
used, and we will need to check that whichever form we choose is
compatible with the majority of the database systems used in the VO.
Based on a quick look at the some of the popular database servers it
looks as though POSIX may be the best standard to adopt.
Note : Choosing the SQL standard syntax would make it much harder to
implement the FindNodes operation without using a database server.
If we choose POSIX standard regular expressions, then it may still be
possible to implement the FindNodes method without using a SQL database.
More information about the vospace