<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi,<div><br></div><div>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.<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 20 Feb 2024, at 18:33, Russ Allbery <eagle@eyrie.org> wrote:</div><div><pre style="caret-color: rgb(0, 0, 0); font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: sans-serif; white-space: pre-wrap; overflow-wrap: break-word;">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.
</pre></div></blockquote></div>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 </div><div>services - (Though I note that Joshua has apparently handwritten these <a href="https://github.com/spacetelescope/vo-openapi/tree/main/openapi/uws">https://github.com/spacetelescope/vo-openapi/tree/main/openapi/uws</a>) - I think that we should find </div><div>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).</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite" style="color: rgb(0, 0, 0);"><div>On 21 Feb 2024, at 10:18, Molinaro, Marco <marco.molinaro@inaf.it> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family: monospace;"><br></div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">This provides only a sync GET interface without capabilities or<br>availability. For a more fully-fleshed example, we'll want to add an async<br>interface with UWS and models for capabilities and availability. I plan on<br>working on that next if this is a suitable starting point.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family: monospace;">I wonder if it's better to stick to the current</div><div class="gmail_default" style="font-family: monospace;">ConeSearch-1.03, which has no POST.</div><div class="gmail_default" style="font-family: monospace;">I'd like this discussed too.</div></div><div> </div></div></div></div></blockquote><br class="Apple-interchange-newline"></div><div>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. </div><div><br></div><div>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”.</div><div><br></div><div>Cheers,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Paul.</div><div><br></div><div><br></div></body></html>