VOSpace WSDL

[Guy Rixon]

Paul,

here are some thoughts on the RC1 WSDL.

1. We'd best be careful about "using up" the namespace URI for the final
release in one of the release candidates. Each time we put a file on the wiki
we effectively release it, so best to have different namespace URIs for each
release candidate and none of them clashing with the final release.

2. Once we finish the WSDL and .xsd, we don't want to change them at any point
in the VOSpace-1 series. We might release v1.1 of the standard text with some
clarifications, but I'd really like to freeze the schemata.

3. The point above means that we shouldn't have closed enummerations of things
that might be extended later. That means particularly things like data-set
format & transport protocol, where implementors are allowed to extend, but
in general all ennumerations are dangerous. For example, we may find that we
want a DELETE permission that is distinct from WRITE, and we may want to allow
extra node types. We discussed using URIs to name these things and validating
the names in code, not in the schemata; I'd prefer that.

4. In the WSDL, I see that you prefer global elements with encapsulated types
over global types. What's the reasoning here? My impression was that global
types worked better in data-binding tools.

5. Would it be feasible to refactor all the types from the WSDL into the .xsd?
That would allow implementors the greatest choice of data-binding tool and the
greatest flexibility in working the SOAP. SOAP-specific tools like WSDL2java
shouldn't notice any difference. I recognize the principal of putting in the
WSDL those structures that only occur in SOAP messages, but I wonder if that
is a practical benefit. I'd prefer to have the definitions where I can get at
them with, e.g., XMLbeans.

6. VOSpaceResponse: where do the message and status elements come from? I
can't see them in spec for, e.g., deleteNode, for which the
response message is a VOSpaceResponse. If we're going to have a
VOSpaceResponse (and I'd prefer a named response message for each operation,
for symmetry), then it should be an empty type.

7. Case of identifiers: it's a bit mixed at present. Can we standardize on
initial capitals or lack thereof for all elements? Don' mind tweaking the spec
document to match if we can be consistent in the schemata.

8. You've got a typo for the name of the transferStatus element: missing its
third t.

9. What's VOSpaceDescriptor (as distinct from VOSpaceBaseDescriptor) for in
the .xsd? It doesn't seem to be used in the WSDL.

10. VOSpace-1 doesn't specify permissions, so we don't really permissions
structures in the current schemata. I realize that they aren't used in the
WSDL, but I'd prefer to keep them out of the .xsd as well until we've
discussed them more. bear in mind that the .xsd for VOSpace-1 may be a full
recommendation before we've had time to validate the permissions stuff.

Cheers,
Guy

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523