1.0rc1 WSDL issues

From: Matthew Graham <mjg-at-cacr.caltech.edu>
Date: Wed, 14 Jun 2006 12:06:51 -0700


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 Received on 2006-06-14Z21:07:35