On 13.06.2006, at 18:44, Guy Rixon wrote:
> 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.
I think that the practical advantages of working in the final namespace at this stage outweigh any theoretical idea that we have published something into the namespace, because we have not actually published until the date that we say that the standard is published, and we make no guarantees of interoperability for software using these schema until after that date.
Given that I suspect that we will go through quite a few rapid release candidates in the next few weeks, the practical advantages of sticking to the final namespace are than if you have set up code generation, written clients/server depending on a particular namespace it is a bit of a pain to go through changing all the places that references might occur to that particular namespace
>
> 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.
agreed,
>
> 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.
I share your reservations about the enumerations (the extensibility of which is only a problem because of the peculiarities of XML schema language), but I am also concerned about not having a mechanism for publishing these enumerations in a fashion that code generation tools can use to aid in interoperability.
I am also against the use of URIs in many of these cases as they are pretty unnatural cf WRITE and ivo://ivoa.net/vospace/write - the first has a "natural" interpretation and could even be used directly as the string to present to the user when describing the permission where the URI could not. In addition for things like the transport protocol it is far better to use the common well-known name for the protocol e.g. ftp rather than introducing an indirection layer for the name via a URI, so that people can immediately use their domain knowledge to recognise what is being referred to.
One compromise could be to have the enumerated lists published in a different namespace, but not use them as types to restrict the values in the formal WSDL. These enumerations could then be updated for a V1.1 release without directly affecting the WSDL contract
>
> 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.
The style of the WSDL comes from the original VOStore WSDL, which I believed (though I might be wrong) was a version of the wrapped literal style that was "favoured" by .Net. A goal of the design of this WSDL should be that it produces "natural" interfaces when using as many different code generation tools as possible. My personal experience is pretty much limited to Apache Axis and as such would welcome feedback from people trying different 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.
I believe that any tool that would help you in creating the actual SOAP messages would always use the WSDL as source - think that as long as you do not use soap encoding this is also true for XMLBeans. I think that I would prefer to put everything in the WSDL file directly rather than make the split if the SOAP message specific parts go into the split file, as remember in wrapped literal there is a "wrapping" layer that the code generation tools typically deal with themselves and do not present at all in the interface that they give the programmer.
>
> 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.
A deliberate ploy to provoke such a response - I too think that some
sort of status message would be more generally useful in other
operations - this sort of thing did exist in VOStore, but then got
replaced in many operations by a VOSpaceNode as a return value - so
yes I think that both a VOSpaceNode and a VOSpaceResponse would be
appropriate in many cases - however, I am unclear about what you mean
by 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.
mea culpa - my java habit of starting instance variables with lower
case - I will make consistent
> 9. What's VOSpaceDescriptor (as distinct from
> VOSpaceBaseDescriptor) for in
> the .xsd? It doesn't seem to be used in the WSDL.
again left from some earlier experimentation - I will remove.
>
> 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.
It was left there from some experiments... I will remove... Received on 2006-06-14Z11:28:22