1.0rc1 WSDL issues
mjg at cacr.caltech.edu
Wed Jun 14 12:06:51 PDT 2006
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
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.
More information about the vospace