ENH: Declaratively define new-style standard IDs in Servicetype constraint

[stvoutsin]

The Servicetype constraint handled sia2, hats, and hips through separate elif branches, raw SQL strings in extra_fragments and a fragile string-comparison.

This adds a module-level NEW_STYLE_STDIDS dict mapping the standard shorthand keys to its LIKE patterns and replaces extra_fragments with a like_patterns set.

With this approach adding a new new-style standard now requires a single line in NEW_STYLE_STDIDS.

Does this address #707 the way you were thinking @msdemlei ?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.54%. Comparing base (66e0cb2) to head (f14fabb).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #744      +/-   ##
==========================================
+ Coverage   79.52%   79.54%   +0.01%     
==========================================
  Files          91       91              
  Lines       10293    10293              
==========================================
+ Hits         8186     8188       +2     
+ Misses       2107     2105       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[msdemlei]

This is much better than it was before, thanks.

However, now that I look I'm pretty sure the hips identifier is not what we want. What's in there right now will find hipslists, which is not something that's useful with pyvo at this point.

The pattern should be for hipses themselves and hence: ivo://ivoa.net/std/hips#hips-1.%.

Since this probably hasn't been in use much, I'd be fine changing this with this PR and much commenting. If you don't change it right here, let's make another PR for that right away before people become confused.

I also eye the hats identifier with suspicion. The HATS note doesn't say anything about capability ids yet; let's take that debate to the registry list; HATS folks: you should go there anyway, because once you are writing ivo://ivoa.net/std/hats, there should something corresponding to that in the registry, and we can help you with that.

[stvoutsin]

This is much better than it was before, thanks.

However, now that I look I'm pretty sure the hips identifier is not what we want. What's in there right now will find hipslists, which is not something that's useful with pyvo at this point.

The pattern should be for hipses themselves and hence: ivo://ivoa.net/std/hips#hips-1.%.

Since this probably hasn't been in use much, I'd be fine changing this with this PR and much commenting. If you don't change it right here, let's make another PR for that right away before people become confused.

I also eye the hats identifier with suspicion. The HATS note doesn't say anything about capability ids yet; let's take that debate to the registry list; HATS folks: you should go there anyway, because once you are writing ivo://ivoa.net/std/hats, there should something corresponding to that in the registry, and we can help you with that.

Thanks for reviewing the changes. I've updated accordingly, removing HATS for now until the note adds capability ids and changing hiplist to hips-1. Let me know if you spot anything else needing change and in the meantime I will also contact folks involved with writing the HATS note about amending the note accordingly.

[bsipocz]

This is now a breaking change, with this change we remove functionality that handles hats resources, please don't remove it.

[stvoutsin]

Ok I've reinstated and have also contacted the HATS folks to look into registration of the standard id.

[bsipocz]

yes, I promised writing up a paragraph about it in the note 😄

[msdemlei]

On Wed, Mar 25, 2026 at 01:51:37PM -0700, Brigitta Sipőcz wrote: yes, I promised writing up a paragraph about it in the note 😄

Oh wow, I'm delighted to see there are already 41 of these registered. Excellent. I'm not a *great* fan that the standard key is called "hats", because that just repeats the standard name, and I'd have preferred if this named, in this case, perhaps a specific serialisation or access mode. For instance, from skimming the document it seems current HATS uses Parquet in the tiles, and I could totally see that some day we'd like to use something else there. So, if we did this from scratch, I'd suggest to perhaps use ivo://ivoa.net/std/hats#parquet-1.0 or so. But since the identifier comes from two authorities already and is used in pyvo, too, I'm fine with going for practicality over purity and leave the identifier as it is. Who knows if we'll ever need other standard keys in the first place? I volunteer for reviewing the PR on hats discovery.

[msdemlei]

Thanks!