There are some other issues that the WSDL still contains that I am
not sure of the current consensus.
- Callbacks for the data import/export operations.
- 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.
- 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?
- ChangeOwner operation - is this fundamental enough to deserve
inclusion?
- 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.
- 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).
Paul.
Received on 2006-06-14Z12:15:38