[p3t] A thought on DataLink in a JSON-based protocol

Paul Harrison paul.harrison at manchester.ac.uk
Mon Jun 17 12:06:27 CEST 2024



> On 15 Jun 2024, at 03:07, Russ Allbery <eagle at eyrie.org> wrote:
> 
> This Message Is From a New External Sender
> You have not previously corresponded with this sender. Please exercise caution when opening links or attachments included in this message.
> Paul Harrison <paul.harrison at manchester.ac.uk <mailto:paul.harrison at manchester.ac.uk>> writes:
> 
> > I had had a similarish idea a while back
> > https://urldefense.com/v3/__https://github.com/ivoa-std/DataLink/issues/53__;!!PDiH4ENfjr2_Jw!Cmb9PTQkao9ZyEFswVjHflIUItaWU8unIypaEvztiAmj4ukrTlxDuG6NIQ7QlyiJjt6OUgkNT6v-1-c2RvHSrYo$[github[.]com]
> > <https://urldefense.com/v3/__https://github.com/ivoa-std/DataLink/issues/53__;!!PDiH4ENfjr2_Jw!Cmb9PTQkao9ZyEFswVjHflIUItaWU8unIypaEvztiAmj4ukrTlxDuG6NIQ7QlyiJjt6OUgkNT6v-1-c2RvHSrYo$[github[.]com]> - I feel that an
> > openAPI description would be way too low level for this description,
> > however. You will see that I even made the heretical suggestion that
> > perhaps the service description did not need to be embedded within
> > VOTable – that removes a lot of problems…
> 
> Thanks for this pointer!  This was an interesting discussion.
> 
> I'm not entirely sure what you mean by "low level" when it comes to
> OpenAPI, since I think of an OpenAPI specification as roughly at the same
> level of the current DataLink service descriptor (list of parameters with
> their types, MIME type of the response, etc.), just considerably more
> comprehensive in the set of things that it can describe.
> 
> That said, the more I've thought about this, the more I think that
> specifying services using all of OpenAPI would just be Too Much for client
> implementors.  The spec allows too many things, trying to implement them
> all would be impossible, and trying to select the important bits would
> probably be overwhelming.  That leads me back to some sort of simpler
> service description, perhaps inspired by OpenAPI and similar languages.
What you say above is more or less what I meant by “too low level” - It we assume that the
way that you interact with the service is more or less UWS (or perhaps some extension of)
then all that needs to be specified is the input and output parameters, not low level things like HTTP response
codes.

This was the idea behind parameter description language https://ivoa.net/documents/PDL/ — unfortunately there has been
pretty much zero take up of this standard and clearly it needs some revision - however, I believe the general approach 
of separating out the parameter descriptions is a good one - it would be fairly easy to
generate full OpenAPI service descriptions from the parameter descriptions and the UWS “pattern”.

Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/p3t/attachments/20240617/b09ae979/attachment-0001.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/20240617/b09ae979/attachment-0001.p7s>


More information about the p3t mailing list