VOSpace 1.1 Working Draft

[Dave Morris]

Draft looks good.
Some initial thoughts :

Discussion point in section 2.1
Should ContainerNode include a list of capabilities.
Yes - If I remember correctly, the capabilities element was added to 
provide support for external services like SRB and iRODS.
In which case it is perfectly acceptable to publish an iRODS capability 
on a ContainerNode.

Section 2.1.2 (inheritable properties)
What is the use case for inherited properties ?

Discussion point in section 2.1.2
If an inheritable property is also declared on a child, which value 
takes priority ?
My guess would be that the child setting should take precedence for that 
child and any nodes below it.
Otherwise, setting the property on the root node would fix that property 
for all nodes in the tree.

Discussion point in section 3.1.3
Should we use the getProperties response to denote properties as 
inheritable ?
No - If we are going to have inheritable properties, then the flag to 
denote a particular property as inheritable has to be external to any 
one individual service (global property registration ?) and all services 
must treat the property in the same way. Otherwise we would end up with 
some properties that were inheritable in one service and not inheritable 
in another.

Section 3.2.4 (findNodes)
I know that we always planned to add this to vospace-1.1.
However, I would like to propose that we make this an optional part of 
the specification.

The only reason I suggest this is that up to this point, it would be 
theoretically possible to create a simple implementation of the node and 
data access methods of a vospace-1.1 service using a scripting language 
like PHP, without requiring a database behind it. Adding the findNodes 
search would make it more difficult to implement without resorting to 
using a full scale database server behind it.
 
Now that we are moving to the new registry schema, with multiple 
capabilities for a service, it would be easy enough to declare this as 
additional capability.
    * A standard vospace-1.1 service (without findNodes) would only 
declare a vospace-1.1-core capability.
    * A service that also implemented findNodes could declare both the 
vospace-1.1-core capability and a vospace-1.1-find capability.

The two capabilities could still be implemented within the same 
WebService, in which case the two capability elements would contain the 
same endpoint address.

Making it optional would also prevent disagreements about the query 
syntax from stalling the acceptance of vospace-1.1-core.

Discussion point in section 3.2.4.1
Should we allow wild cards in the property URIs ?
No, probably not at this stage - simplest solution first, add 
complications if we need them.
The proposed schema for MatchType defines the uri attribute as 'xsd:anyURI'.
If we allowed wild cards in the property URIs I suspect it would make 
this a lot more complicated.

Hope this helps,
Dave


Matthew Graham wrote:

> Hi,
>
> The Working Draft for VOSpace 1.1 is now available at:
>
> http://www.ivoa.net/Documents/cover/VOSpace-20080311.html
>
> You can find the WSDL, message schema and discussion page for the  
> discussion points in the WD on the VOSpaceHome wiki page 
> (http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome ).
>
>     Cheers,
>
>     Matthew