On Mon, 13 Jun 2022 at 14:49, Dave Cridland <[email protected]> wrote: > On Sun, 12 Jun 2022 at 18:02, Matthew Wild <[email protected]> wrote: >> >> What I'm trying to prevent is leaking implementation-defined esoteric >> syntax to end users. That at least one implementation is already >> exposing Lucene's special query syntax via this XEP is enough to >> convince me that simple searches are worth pushing for. > > Right, exposing something like Lucene is clearly insane on many levels. > > I'm not convinced that exposing any sort of syntax is bad, though - allowing > the kind of syntax that websearch_to_tsvector allows seems harmless. But if > we're faced with people that genuinely think exposing a search language, > rather than interpreting an end-user search string, is sensible then we have > clearly lost anyway.
Yes, I agree that websearch_to_tsvector() would be absolutely fine too. However it's not permitted by my proposed text mainly because I'm not sure how to codify that in a XEP without beginning to dictate the actual search syntax. Which is something I don't really want to do, because this isn't a Postgres-driven XEP and there may be (completely acceptable) syntax differences in other equivalent implementations. If "simple searches" are not going to fly, maybe we could instead settle for some non-normative text advising implementations against exposing "implementation-specific syntax", or something along those lines. In addition to mandating <desc> for anything more advanced than the simple search defined in my current proposal. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
