pattern matching in SLAP 2 protocol
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Tue Mar 17 11:12:27 CET 2026
Dear Colleagues,
On Mon, Mar 16, 2026 at 02:06:30PM +0100, nicolas via apps wrote:
> While discussing this with Markus, it appeared to be the first time
> RE-like expressions are used in an IVOA protocol. This choice could
> set a precedent. We would therefore like to get your opinion:
> should we stick with SQL patterns or use shell patterns?
Actually, I think this should one day be DALI material. For
instance, from long experience I'd say SSAP's TARGETNAME or
COLLECTION (and their future DAP equivalents) should share that
pattern syntax. So, I'm sure it will pay to think a bit about it now
to avoid having different pattern languages down the road.
As Nicolas says, we could have SQL patterns and just quote the SQL
spec for the whole story, including an escape mechanism (while
matching % will probably be rather rare, at least _ and * absolutely
could be in the various fields folks may want to query with such
patterns).
While I'd be fine with going the SQL route, my personal baseline (but
then I'm spending much of my life in unix shells) would be to include
(essentially) the documentation of python's fnmatch module. That's
*, ?, [seq], and [^seq]. The escaping mechanism there is using
character classes (where I think []] and [[] need a bit of care to
avoid ambiguities).
*If* one were ever to implement this from scratch, the python
implementation (fnmatch.py) is 192 lightly documented LoC, which I
claim is reasonable.
More realistically, though, these patterns would usually be
translated into SQL patterns, and that's the weak point: LIKE doesn't
do character classes. So, perhaps we should dump these and use * and
? only, and then escape with a backslash? That would rather
trivially be translated into LIKE patterns, and character classes are
perhaps not so important after all?
Thoughts welcome. In particular: Among your friends and colleagues,
how many still regularly type shell patterns?
-- Markus
More information about the apps
mailing list