GWS II discussion topics

[Dave Morris]

Dear GWS members,

Just a quick note to update you on the GWS II session on Thursday 
morning.

Please note the location has been changed to room 216 in order to better 
support a hybrid local+Zoom discussion.

The session will look at the changes suggested by the Rubin team based 
on their experience implementing SODA.

See
https://sqr-063.lsst.io/

We invite everyone to join the discussion. In particular we would like 
to hear from developers or maintainers of clients and services.

Do you agree/disagree with the proposed changes, and what would the 
impact be for your project ?

Due to the nature of the changes the initial part of the discussion will 
be technical. However, we would also like to address the implications 
for the IVOA standards and community.

Will these changes result in major or minor version changes to all our 
specifications ? If so, how would we manage that transition process.

Long term, how do we manage the VO with both old and new services in 
operation. In some cases, services offering both old and new 
functionality at the same time.

If we want to make the transition easier, can we provide resources to 
help maintainers of older software update their implementations.

In several cases, the IVOA standards may be technically correct, in 
terms of the original HTTP specifications. However, they are not 
consistent with the patterns used by modern web-service development 
tools and frameworks like Spring, Quarkus, FastAPI, or DJango. Requiring 
developers to take extra non-standard steps adds friction to the 
acceptance and uptake of IVOA standards.

We would like to achieve three results from the meeting :

* Agreement on which changes we agree on.
* Agreement on which changes we disagree on.
* A plan for breaking the log jam and moving forward with the changes we 
agree on.

Discussion topics include:

POST and simple requests
POST with application/x-www-form-urlencoded content means UWS vulnerable 
to CSRF attacks.

GET for state-changing operations
The general recommendation for HTTP requests is that GET requests should 
be idempotent. Allowing GET requests to change server side state means 
it is vulnerable to CSRF attacks.

Case-insensitive parameters
Allowing case insensitive, UPPER, lower, and MixedCase parameter names 
makes it just that little bit more difficult to develop IVOA services.

Mixing query and POST parameters
UWS says that ?PHASE=RUN can be added to the query portion of the URL 
when creating a new job. While this is technically correct as far as the 
HTTP specification goes, it is not consistent with the patterns used by 
modern web-service development tools and frameworks.

XML responses
Many Python web frameworks have limited support for XML, making it 
harder to develop services. Again, it is not impossible to develop XML 
solutions, but requiring developers to take extra non-standard steps 
adds friction to the acceptance and uptake of IVOA standards.

Note - this does *NOT* mean deprecating or replacing VOTable.

This suggestion is primarily looking at the responses from services such 
as UWS, rather than the VOTable results from our data access services.

There may be a case for looking at an alternative JSON serialization for 
VOTable, which would be a different discussion; but even then, this 
would not change the data model that VOTable represents.

Error handling
There are several places where our standards either don't address how to 
handle errors, or they simply allow plain text error messages. Defining 
structured error messages will enable clients to provide better feedback 
to their users.

This is just a summary. The full list of suggestions and more details 
are in available the report from the Rubin developers.
https://sqr-063.lsst.io/

Looking forward to the discussion,
-- Dave

--------
Dave Morris
Research Software Engineer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------
AIMetrics: [{"name": "ChatGPT","contribution": {"value": 0,"units": 
"%"}}]
--------