VOSpace 1.1 Working Draft
dave at ast.cam.ac.uk
Wed Mar 19 19:23:44 PDT 2008
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
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
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 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
* 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 126.96.36.199
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,
Matthew Graham wrote:
> The Working Draft for VOSpace 1.1 is now available at:
> 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 ).
More information about the vospace