Updated VOSupportInterfaces spec

[Ani Thakar]

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.