On Wed, 14 Jun 2006, Paul Harrison wrote:
>
> On 13.06.2006, at 18:44, Guy Rixon wrote:
>
> > 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
I disagree with this most strongly.
>
> >
> > 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
The distinction is between closed lists, which can only be extended by reissuing the spec and schemata, and open lists which can be extended by implementors and/or users. Transport protocol is clearly open; permissions could be closed; the others are less clear. The point is, if we close a list and then extend it, we replace the schema with a new one. That means that _everybody_ then has to support both old and new schemata even if they don't want to support the new feature. Changing schemata is merely annoying when we have to do it in protoypes, but it's disasterous in the wider IVO.
> >
> > 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.
So what are the requirements for "wrapped"? AFAIK, it's only that the SOAP body contain a single child element that is named after the operation. If we do that in WSDL, does it matter whether we use global types or global elements? (Any .NET users care to comment?)
>
> >
> > 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...
Empty type instantiated like this <VOResponse/> and enforced to be that way in schema: written as a xsd:ComplexType with no children IIRC.
> >
> > 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...
>
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-14Z12:18:28