Updated VOSupportInterfaces spec

[Guy Rixon]

Thanks Ani.

You're right, .NET does default to doc/literal. IIRC, the whole idea of
"wrapped" mode, where rpc/literal gets morphed into doc/literal, is from .NET.
If we only had SOAP bindings to consider, then it wouldn't matter as
rpc/literal and wrapped doc/literal amount to the same messages on the wire
and the toolkits don't care about the differences; this is the normal situaton
for SOAP implementors. Since we're wierd enough to want non-SOAP bindings, the
differences matter a lot to us and I think rpc/literal SOAP saves us some
complications. Let me know if this a problematic in .NET.

Cheers,
Guy

On Mon, 7 Nov 2005, Ani Thakar wrote:

>
> Hi Guy,
>
> I agree about combining the WSDL and about the naming convention
> consistency.  I'm partial to camel-cased, but IIRC I inherited the names
> in the document and didn't bother to change them.  I'll take care of
> combining the WSDL and changing the names.
>
> As for the rpc/literal, I don't know enough about WSDL/WS to really have
> an informed opinion about it, so  I'll defer to others' judgement on
> this.  I guess .NET defaults to document/literal.
>
> 	Ani
>
> On Fri, 4 Nov 2005, Guy Rixon wrote:
>
> > Ani,
> >
> > thanks for working on this. It's good to get some progress.
> >
> > getRegistration isn't mandatory; only getAvailability is considered mandatory
> > at present.
> >
> > All these interfaces have to be mixed in with another WSDL contract to produce
> > a useful service with a single port. Therefore, I suggest that we combine the
> > WSDL documents, putting the mandatory and optional interfaces into one
> > contract. We need to add language to the specification explaining that the
> > implementor picks apart the "normative" WSDL contract.
> >
> > Would you like to have a go at combinging the WSDL?
> >
> > I see that you have different messages for the SOAP and HTTP-get/post binding,
> > but with equivalent semantics:  the SOAP binding uses messages with complex
> > types and the HTTP bindings use lists of type parameters. I understand that
> > this is because HTTP-get _has_ to use lists of simple types, but I think that
> > calls into question the details of the SOAP binding.
> >
> > Presume that we want to bind the _same_ port type to SOAP and to HTTP-get,
> > which we do. Presume that we want to bind _all_ the operation in each case
> > because that makes the contract much neater and easier to understand. Presume
> > that all the messages _can_ be expressed as simple types based on W3C XML
> > schema types, which is true here. In that case, should the SOAP binding not be
> > rpc/literal rather than document/literal? It's what the RPC style is for. It
> > would reduce the number of messages and would eliminate the HarvestWebLog and
> > HarvestServiceLog types from the contract.
> >
> > It might be helpful to make consistent the capitalization of operation names
> > and names of message parts. We have a mix at present. I suggest that the names
> > of parts should be camel-cased since they are like field in objects. The names
> > of operations could either be camel-cased because they are like methods of an
> > object that represents the service, or they could have initial capitals
> > because they are like objects that contain the message parts as fields. I
> > don't mind which, but I think we should be consistent.
> >
> > Cheers,
> > Guy
> >
> >
> > On Thu, 3 Nov 2005, Ani Thakar wrote:
> >
> > >
> > > Hi all,
> > >
> > > I've posted an updated VO Support Interfaces draft spec, version 0.23
> > > at:
> > >
> > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupportInterfaces-0.23.pdf
> > >
> > > This includes changes to the logging interfaces to fix some missing
> > > information as well as to update the interfaces to send output to a
> > > logging VOStore.   This part will still need tweaking before it is
> > > finalized, of course.  I've also added a note about access/security for
> > > the logging VOStore.
> > >
> > > I posted the WSDL for the updated services in VOSupportInterfaces.wsdl,
> > > but I noticed that there were 2 WSDL documents for the support
> > > interfaces: VObsServices.wsdl which contains the getAvailability and
> > > registry metadata interfaces, and the other one containing the logging
> > > interfaces.  Since the latter are non-mandatory, I've updated the
> > > support interfaces section to include both WSDL files, one for mandatory
> > > support interfaces and the other for non-mandatory (logging) interfaces.
> > > I updated the comment in the VObsServices.wsdl file to reflect the fact
> > > that the logging WSDL was in a separate document.
> > >
> > > However, I note that the current draft spec contains identical
> > > language, "All VO services *should* implement ..." for all the current
> > > support interfaces, mandatory and non-mandatory.  I guess this should be
> > > changed to "must implement" for the mandatory interfaces, right?
> > >
> > > Please send me comments, questions if you have any.  Cheers.
> > >
> > > 	Ani
> > >
> > > --
> > > Aniruddha R Thakar,  Research Scientist,  The Sloan Digital Sky Survey
> > > Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695
> > > 410-516-4850 fax:410-516-5096  thakar at jhu.edu www.sdss.jhu.edu/~thakar
> > > -----------------------------------------------------------------------
> > > Love is like war; easy to begin but very hard to stop. [H.L. Mencken]
> > >
> >
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> >
>
> --
> Aniruddha R Thakar,  Research Scientist,  The Sloan Digital Sky Survey
> Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695
> 410-516-4850 fax:410-516-5096  thakar at jhu.edu www.sdss.jhu.edu/~thakar
> -----------------------------------------------------------------------
> Artificial Intelligence is no match for natural stupidity.
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523