Fwd: QT4CG meeting 069 draft minutes, 12 March 2024

Sorry, I replied just to Michael, but intended to reply  all:

---------- Forwarded message ---------
From: Dimitre Novatchev <dnovatchev@gmail.com>
Date: Wed, Mar 13, 2024 at 3:34 PM
Subject: Re: QT4CG meeting 069 draft minutes, 12 March 2024
To: Michael Kay <mike@saxonica.com>


> The lack of support for descending keys in the 3.1 version of fn:sort was
a big gap,
> we don't want to repeat it. For numeric keys there is an easy workaround
by negating the value,
> but there is no easy workaround for strings.

I think that you, Michael, submitted  a proposal for fn:revert, or
fn:negate - sorry, don't remember the exact name.

This function can easily handle strings - produce a "string complement" in
the value space for a particular collation.

For a simplified example, revert("abc") would produce "zyx" . This is
doable and really valuable.

> I basically can't see any reason for making fn:ranks different from
fn:sort in areas where they are doing the same thing,
> other than the fact that you don't like the design, and I don't think
that's a good enough reason.

Not anything personal, but as a future user of this function I would hate
to enter unnecessarily *() *for the collations argument, every time I call
this function.
We often neglect how the user would feel having every time to specify
an *unnecessary
*argument: *time-consuming, distracting, error-prone*.

If we cannot mend `fn:sort`, then we at least should not inherit bad design
features from it.

Thanks,
Dimitre

On Wed, Mar 13, 2024 at 2:50 PM Michael Kay <mike@saxonica.com> wrote:

>
> > I redefined the solution for  producing all  needed sort-keys with a
> single key() function as shown  below.
> >
>
> The reason for having multiple sort key definitions is that you typically
> want to apply different criteria to each one - ascending/descending,
> collations, etc.
>
> The lack of support for descending keys in the 3.1 version of fn:sort was
> a big gap, we don't want to repeat it. For numeric keys there is an easy
> workaround by negating the value, but there is no easy workaround for
> strings.
>
> I basically can't see any reason for making fn:ranks different from
> fn:sort in areas where they are doing the same thing, other than the fact
> that you don't like the design, and I don't think that's a good enough
> reason. If someone drives two cars, they want the pedals on both to be in
> the same place, rather than having every designer do their own thing.
>
> Michael Kay
> Saxonica
>
>
>


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.