pattern matching in SLAP 2 protocol

[Pierre Fernique]

Dear Apps members,

Mes deux sous.
In all of my codes, related to IVOA, or not related, I always use ?, * 
wildcards: MocServer, Aladin Desktop tree filter, Glu browser. And if 
required, I extended it to a full regex syntax (if embraced by /.../) - 
rarely need.

Unless I'm mistaken, these wildcards are also used in all Unix and 
Windows shells, Apache and Nginx rewrite rules, Elasticsearch, etc.

In my experience, I've never seen anyone use % wildcards outside of an 
SQL/DB context.

Cheers
Pierre

Le 17/03/2026 à 11:12, Markus Demleitner via apps a écrit :
> 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
>
>
>
>
>