1.0rc1 WSDL issues

Matthew Graham mjg at cacr.caltech.edu
Wed Jun 14 12:06:51 PDT 2006


Hi,

Gosh, you guys have been busy :-) so here are my comments:

1. Operation names: OK, change them if you want.

2. Namespace URIs: I think that if we have multiple release candidates 
floating around within a short time frame then different namespaces are 
essential to avoid confusion.

3. Enumeration: I agree with closed enumerations only where absolutely 
necessary.

4. URIs: I thought that it was agreed by the WG in Victoria that we 
would use URIs: I certainly am in favour of them.

5. doc/lit wrapped style: The rules are: the input message has a single 
part; the part is an element; the element has the same name as the 
operation; and the element's complex type has no attributes. I favour 
using global types since it promotes reusability.

6. Callbacks: Asynchronous behaviour is a VOSpace-2 feature so these 
should be removed.

7. ChangeOwner: This is VOSpace-2 functionality and should be removed.

8. GetPropertyKeys: this is a useful suggestion which we should include.

9. Transports/Formats: this information should be in the registry entry 
but should also be returned from the VOSpace. I know users who will not 
use the registry but will want to talk to a VOSpace directly.

10. Name vs. identifier: We agreed in Victoria that requests could use 
both but responses would always just supply the full identifier.

11. Mandatory protocols: We discussed this back in October and could not 
actually come up with a list so I think that you have to stick with a 
list of suggested protocols and hope that most implementations cover 
some. I'm working on an implementation that uses http but also has 
support for jparss.

12. DIME: In Madrid, we agreed that we would deprecate DIME as it itself 
has long been deprecated. With the support for MTOM now in Axis 2, WSE, 
XFire, etc., I would rather that we suggest MTOM as the attachment 
mechanism. DIME is also incompatible with WS-Security so you cannot 
include a DIME attachment on a secure SOAP message. Attachments are just 
another form of transport mechanism and I think we should keep messaging 
and transport separate so the import and export operations should not 
accept attachments: there should be separate endpoints for this as 
suggested in the spec.

13. WSDL vs spec: I worry that we seem to be attempting to define 
VOSpace from both whereas really the WSDL should just present an XML 
description of what the spec says. Also this WSDL seems to be quite 
different from what the spec defines to be the request/responses and the 
exception names - we really should be working with a version that is as 
close as possible.

    Cheers,

    Matthew






More information about the vospace mailing list