VOSpace 1.1 changes

Mon May 19 02:44:38 PDT 2008

Hi,

Thanks very much for all of these. I'm aware of most of the WSDL  
errors and will amend them.
Inherited properties and FindNodes are in my list of open issues so  
hopefully there will be some fruitful discussion about them. In case  
there is apathy, we will follow your suggestions: inheritable  
properties, in particular, were an absolute swine to implement and  
raised the very points that you have made.

	Cheers,

	Matthew

On May 19, 2008, at 11:20 AM, Dave Morris wrote:

> 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
>
> ----
> 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,
>
>   <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>
>       ....
>   </wsdl:portType>
>
> 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>
>   </wsdl:binding>
>
> 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.
>
> ----
> 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 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.
>   ----
> 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: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"/>
>       ....
>   </xsd:complexType>
>
> 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).
>
> ----
> 4) LinkFoundException
> 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
>   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>
>       ....
>   </xsd:complexType>
>
> ----
> 6) Inherited properties.
>
> 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.
>
> ----
> 7) FindNodes
> 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.
> 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
>   http://www.oracle.com/technology/products/database/application_development/pdf/TWP_Regular_Expressions.pdf
>
> 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
>