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.
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
Received on 2008-03-20Z03:24:21