Call for proposals for SIAP Version 2

[Roy Williams]

>  Galactic coordinates are pretty important and adding support
> for these to POS is a reasonable thing to consider.

The more complicated is the specification of conesearch/SIA, the smaller the
number of implementations! It is the NVO that should build the middleware --
so that users get a rich set of services, but the entrance cost for
publishers is low low low.

One way to do the galactic coordinates is to specify SIA in terms of a
single coordinate system (as it is now), and have a middleware service to
make the coordinate conversion, which in turn calls the elementary service.

> The broader question
> is do we want to generalize the query region specification,

Similarly, we could have an elementary service specification that uses only
disks or rectangles, and have middleware to deal with complex regions
through multiple calls to the elementary service.

Just as programmers in the 1960's learned to combine subroutines as
components, so the Holy Grail of Web Services is to combine services as
components. (Your comments welcome).

>  ASU for example specifies
> a more general syntax, .

Let us ask a specific question then: is is possible to convert an arbitrary
conesearch service to an ASU service through appropriate middleware?

> > A key requirement for this to work is that the service provider be able
> > to communicate to the client which query elements it can accept. This
> > will be part of the metadata service request (FORMAT=METADATA).

There is a very general type of conversation that I think we should include
as part of our service specification. Once we can implement this in a
general way, it covers a lot of ground.

Waiter: What type of toast?
Customer: What do you have?
Waiter: White, wheat, rye, ....
Customer: Wheat

Note that lines 2 and 3 can be omitted if the customer already knows the
list of options.

Roy