On Wed, 14 Jun 2006, Matthew Graham wrote:
> 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.
So the answer is to use all global types and global elements only for the top-level messages? This suggests that the .xsd file will be all types and the elements will only be in the schema embedded in the WSDL.
> 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.
If returned directly from the VOSpace service do the answers apply to all nodes of the service or do they differ from node to node?
> 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.
I agree with dumping DIME in favour of MTOM.
> 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.
I don't mind tuning the spec document to match the WSDL if the WSDL exposing things we'd left out. However, we need to expose a matched pair and leave them a few days for comments before going to 1.0. If we really need status messages in the returns I'd rather see their semantics written down before we design the syntax.
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2006-06-15Z09:05:36