Matthew Graham wrote:
> I also intend to move VOSpace 1.1 to Proposed Recommendation in a few
> week's time.
I'm working my way through our vospace 1.1 implementation building a suite of unit tests to check that it returns the correct faults for all the edge cases. (ContainerNotFound, NodeNotFound, LinkFound etc). Copy and move were the most complicated, working on push/pull at the moment.
The spec is fine, but some minor points about copy/move may need
clarification.
(no technical changes, but possibly some extra descriptive text to
clarify what happens in some of the edge cases)
The wsdl needs the fixes raised in May, I'll send you a copy of the version I'm working from at the moment.
I do have one request.
At the meeting in May, you asked if node CapabilityType should have
additional parameters, (I think they are commented out in the current
wsdl). At the time I said they would be nice, but I couldn't think of a
specific use case. Since then I have found a use case, so yes.
Use case :
If the capability represents a SOAP endpoint, then it is difficult to
represent it with just the http endpoint URL.
Example :
If I have a vos 1.1 service that also provides vos 1.0 access to each
container within the vos 1.1 space. The top level vos 1.1 service is
registered in the registry, but the vos 1.0 services for each container
would not be registered. To represent 'access this node via vos 1.0',
you would need the SOAP endpoint of the vos 1.0 service *and* the node
identifier (name) within that service.
It would be possible solve this specific case by mangling the SOAP endpoint to include the identifier, using # or (), but adding params to the node CapabilityType would solve the general case.
Hope this helps,
Dave
Received on 2008-06-26Z13:36:36