[p3t] Simple Cone Search starting point added

[Paul Harrison]

Hi,

I will not be able to attend the next meeting as I am going to be on vacation - However, I did want to make a few points for consideration.

> On 20 Feb 2024, at 18:33, Russ Allbery <eagle at eyrie.org> wrote:
> Some additional notes and cautions:
> 
> * FastAPI is not an ideal OpenAPI schema generator, and I suspect it will
>   not generate exactly the schema that we would want. Please consider this
>   only a proof-of-concept for fast iteration. An OpenAPI schema suitable
>   for publication would likely require some additional manual tweaking.
> 
I fully understand the desire not to write OpenAPI definitions directly, as they are difficult for humans to parse and quickly become very large for reasonably sized 
services - (Though I note that Joshua has apparently handwritten these https://github.com/spacetelescope/vo-openapi/tree/main/openapi/uws) - I think that we should find 
a ‘neutral’ way of expressing the 'source code' for creating the definitions. We do already have an IVOA endorsed solution that has been created for the “schema” part- i.e. VO-DML that should be used, even if the “interface” part is generated in some other fashion (or hand written).

We also need to put in place some linting/testing/code generation facilities against the definitions in several different languages to make sure that we are not doing anything that does not have widespread support.

> On 21 Feb 2024, at 10:18, Molinaro, Marco <marco.molinaro at inaf.it> wrote:
> 
> 
>  
>> This provides only a sync GET interface without capabilities or
>> availability. For a more fully-fleshed example, we'll want to add an async
>> interface with UWS and models for capabilities and availability. I plan on
>> working on that next if this is a suitable starting point.
> 
> I wonder if it's better to stick to the current
> ConeSearch-1.03, which has no POST.
> I'd like this discussed too.
>  

I think that we discussed at the last meeting that we had the freedom to produce v2.0 services that were incompatible with the previous versions - however, I think that if we are going to do this then we might as well be more radical and produce a new “Data access service” that encompasses all of what SCS SIAP and SSAP in a single service definition. 

SCS is a special case in some ways, as it has already sort of been superseded by TAP - I do remember in the discussions around the creation of TAP it was suggested that the URL parameter based way of expressing a query could be an alternative query language to ADQL, but that was never followed up. It might still be true that including the SCS functionality in TAP is a better way to proceed than putting it in a “Data access service”.

Cheers,
	Paul.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/p3t/attachments/20240222/5a3ac455/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/p3t/attachments/20240222/5a3ac455/attachment.p7s>