I would like to request a few changes to the proposed VOSpace 1.1
specification.
Most are just small changes to the document or wsdl that should not need
much discussion.
The last two points, regarding inherited properties and the FindNodes operation may need to be discussed further.
Thanks,
Dave
Although both the LinkFound and ContainerNotFound faults have been added to the definition of the wsdl:portType,
<wsdl:portType name="VOSpacePortType">
....
<wsdl:operation name="CreateNode">
....
<wsdl:fault name="ContainerNotFoundFault"
message="vos.contract.1.1:ContainerNotFoundFaultMessage"/>
<wsdl:fault name="LinkFoundFault"
message="vos.contract.1.1:LinkFoundFaultMessage"/>
</wsdl:operation>
....
The new faults also need to be added to the corresponding operations in the wsdl:binding
<wsdl:binding name="VOSpaceBinding" type="vos.contract.1.1:VOSpacePortType">
....
<wsdl:operation name="CreateNode">
....
<wsdl:fault name="ContainerNotFoundFault">
<soap:fault use="literal" name="ContainerNotFoundFault"/>
</wsdl:fault>
<wsdl:fault name="LinkFoundFault">
<soap:fault use="literal" name="LinkFoundFault"/>
</wsdl:fault>
....
</wsdl:operation>
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 or LinkFoundFault.
".. 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 the VO
would be to create a set of link nodes that point to the data in the FTP server.
This also allows scientists to use LinkNodes with properties to annotate data that is stored in external servers outside the VO.
<xsd:complexType name="LinkNodeType">
....
<xsd:element name="target" type="xsd:anyURI" minOccurs="1"
maxOccurs="1">
....
</xsd:complexType>
However, the XML schema for the LinkFoundFault does allow the target to be null.
<xsd:complexType name="LinkFoundFaultType">
....
<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.
The list of faults for both GetNode and SetNode method should probably include ContainerNotFoundFault (in both the document and the wsdl).
Given the path
vos://service/alpha/beta/gamma/delta
If the link node is at
vos://service/alpha/beta
with a link target of
vos://other/path,
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
vos://other/path/gamma/delta.
In order to enable the client to do this, it needs to know which of the nodes in the original path caused the exception.
vos://service/alpha/beta
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:complexType name="LinkFoundFaultType">
....
<xsd:sequence>
<xsd:element name="node" type="xsd:anyURI" nillable="false">
<xsd:annotation>
<xsd:documentation>
The URI of the node where the link was encountered.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="link" type="xsd:anyURI" nillable="false">
<xsd:annotation>
<xsd:documentation>
The target URI that the link points to.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
....
At the moment, I'm not sure that inherited properties are ready to be
accepted yet.
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.
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.
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.
Postgresql
POSIX yes
SQL yes
http://www.postgresql.org/docs/8.3/interactive/functions-matching.html
MySQL
POSIX yes
SQL unknown
http://dev.mysql.com/doc/refman/4.1/en/regexp.html
Oracle
POSIX yes
SQL unknown
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.
That's all
Dave
Received on 2008-05-19Z11:30:42