Updated VOSupportInterfaces spec

[Guy Rixon]

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