inputParams could refer to PARAM as alternative to FIELD

[mbtaylor]

I have a suggestion/request from ESDC to allow service descriptor inputParam entries to refer by ID/ref not only to FIELDs in the results table but also to PARAMs. The existing text in sec 4.3:

For services where the parameter value(s) come from the "results" resource, the value attribute is empty (value="") and the PARAM includes a ref attribute to indicate the FIELD (column) that contains the values.

does not explicitly allow this possibility, but given the relationship between FIELDs and PARAMs in general, it seems almost implied.

Although the same effect could be achieved by rearranging information in the VOTable document (use a constant valued-service descriptor instead of a referenced PARAM), I understand that at least for the Gaia DataLink documents under consideration doing it like this would make for more straightforward implementation.

I would support this change (clarification?) for DataLink 1.1 and I am willing to write a PR, or open discussion on the mailing list, or add a note on the RFC page, on request. But the editors might consider it too late in the DL1.1 process to include this change to the text. @pdowler what do you think?

[mbtaylor]

On second thoughts introducing this could raise backward compatibility issues: if a DataLink 1.0 client encountered a DataLink 1.1 service descriptor with a PARAM reference it would likely fail to understand it. So maybe not such a good idea at a minor revision. But still interested if other people have thoughts about it.

[msdemlei]

On Tue, Nov 21, 2023 at 01:07:50AM -0800, Mark Taylor wrote: On second thoughts introducing this could raise backward compatibility issues: if a DataLink 1.0 client encountered a DataLink 1.1 service descriptor with a PARAM reference it would likely fail to understand it. So maybe not such a good idea at a minor revision. But still interested if other people have thoughts about it.

I could probably live with the backwards compatibility woes; I'd be curious how many of these 1.0 clients are around in the first place, and how many of those actually implement the full trickery of 1.0 descriptors correctly. I'd volunteer on doing an impact assessment for pyvo if there's interest in that kind of thing. But frankly, I'm not so overly happy to add even more variability to a standard that already confuses many with its many options. If all that's itching ESA is the repetition of a PARAM -- which is machine-generated anyway, so repetition is basically free --, I'd say it's not worth it, in particular because we'd be introducing an id/ref pair where we previously had an immediate value. And id/ref is about the most expensive thing we can write into a standard.

[mbtaylor]

The reason I think this sounds sensible is that conceptually a PARAM is just a non-varying FIELD, so you'd expect PARAM references to work in the same way that a FIELD references do - so perhaps if the original text had been written more thoughtfully it would have said "FIELD or PARAM" where it now says "FIELD". From that point of view this is more like a clarification than adding a new feature.

But backward compatibility issues would apply at least to existing versions of topcat - topcat currently understands service descriptors that reference FIELDs but not PARAMs. And the same may be true of other clients, PyVO included or not.

[Bonnarel]

Le 21/11/2023 à 14:13, Mark Taylor a écrit :

The reason I think this sounds sensible is that conceptually a PARAM is just a non-varying FIELD, so you'd expect PARAM references to work in the same way that a FIELD references do - so perhaps if the original text had been written more thoughtfully it would have said "FIELD or PARAM" where it now says "FIELD". From that point of view this is more like a clarification than adding a new feature. But backward compatibility issues would apply at least to existing versions of topcat - topcat currently understands service descriptors that reference FIELDs but not PARAMs. And the same may be true of other clients, PyVO included or not. — Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMP5LTDCSGCBA6R7V7OIAH3YFSSHNAVCNFSM6AAAAAA7S3QI56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRQHEYDENRQHE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

I think I understand the need and rationale. This looks like a minor change and tend to follow Mark there. From the client side it just a minor change to apply . Do you think that an erratum would be more adapted ?