On Wed, 14 Jun 2006, Paul Harrison wrote:
> There are some other issues that the WSDL still contains that I am
> not sure of the current consensus.
>
>
> 1. Callbacks for the data import/export operations.
Wasn't this to be deferred until VOSpace-2?
> 2. DataObjectReference type contains the idea of a name (expressed as
> a string) and a container that the Object lives in - I am not sure
> that this distinction is still needed now that we have some consensus
> on the vos: URL scheme, as it has built in semantics for expressing a
> container.
I agree that it's unnecessary structure. Just a vos: URI will do.
> 3. DIME transfers - the 0.21 spec mentions a usage of DIME that
> implies that there should be a specific operation that the files
> could be attached to, and by implication this operation should be in
> the interface definition. This was not how I would have envisaged
> DIME working if we allow it as a transport, as it loses the principal
> advantage of attachments anyway, i.e. that the HTTP SOAP call with
> all the necessary data is atomic and synchronous. Would it not be
> better to say that if DIME is specified as a transport then the data
> be attached to the pullDataFromVoSpace or pullDataToVoSpace calls
> themselves?
> 4. ChangeOwner operation - is this fundamental enough to deserve
> inclusion?
Do we really need it for VOSpace-1?
> 5. GetPropertyKeys - not in the spec and an idea that I have had
> basically because I am still a little worried about interoperability
> problems with the completely untyped nature of the property-key pairs
> - particularly as they are expected to carry some fundamental
> metadata about the data objects in the current implementation. This
> call would return the complete list of key names that have been used
> in the VOSpace, which would then allow clients to attempt to be
> consistent in the use of key names - it is not much but at least it
> does provide a mechanism to voluntarily avoid complete anarchy.
I'd support this. It's useful for management.
> 6. Transports/Formats operations - this information could/should in
> principal be in the Registry entry for VOSpace (we need a registry
> extension schema also! and quickly - ideally before the v1.0 rollout
> this summer).
I would be happy for the transports and formats to be listed only in the registration. Will NVO accept this for VOSpace? However, there's a significant distinction lurking: can a space support diffferent transfer protocols for different nodes? If so, then there must be some negotiation operations on the service. E.g., make the requested protocol for a transfer a list of protocols that the client will accept (in order of preference) and let the service fault if it can't do any of them.
> Paul.
>
>
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2006-06-14Z12:28:37