Re: Proposals for new/amended functions: summary

I would like to see the below functions added in the table:
 - Please, add the missing sequence-equal() and array-equal() as proposed
in https://github.com/qt4cg/qtspecs/issues/99

-   Also, please add the missing  op("⊙") from
https://github.com/qt4cg/qtspecs/issues/83#issuecomment-1017884359

 -  I would like to add the function deep-equal-safe(), which was proposed
to be used in https://github.com/qt4cg/qtspecs/issues/119
    Based on the support expressed by people using emoji and even proposing
its best name, it seems that it can be useful not only as support for the
above separate proposal, but in other situations, too.
    This is very similar to the existing deep-equal() but doesn't throw any
errors and is context-free and transitive. In fact, its description is a
merge of the spec descriptions of deep-equal() and op:same-key(), thus it
just reuses the thinking      that had already gone into, discussed and
approved in XPath 3.1. Due to purely technical reasons (Word doesn't
truthfully preserve the formatting when saving to a .md file) the
description of the function is now in pdf format.

Separately, I have a question:

How were the values determined in the columns of the sheet/table in
https://github.com/qt4cg/qtspecs/blob/master/editorial/functions-checklist.pdf,
who determined these value and based on what methodology/principles?
Also,  why are some values completely missing?

What principle was used to group the rows of the table?

Thanks,
Dimitre



On Thu, Aug 11, 2022 at 3:52 AM Michael Kay <mike@saxonica.com> wrote:

> In the hope that we will soon start a process of agreeing the 4.0
> specifications, I have produced a summary table showing proposals for new
> and amended functions for 4.0, which I think would be the best place to
> start the process.
>
> See
> https://github.com/qt4cg/qtspecs/blob/master/editorial/functions-checklist.pdf
>
> In the column "next step" I've classified each proposal as one of:
>
> * approve - means I think we're ready to "take a vote" to accept the
> proposal as is (no discussion needed unless anyone objects). Note that
> these all have good test coverage already.
>
> * discuss - means I think discussion is needed, perhaps because there is
> some detail in the spec that needs to be sorted.
>
> * revise - means further work is needed to flesh out the proposal
>
> Let me know if you think I've omitted or misclassified anything.
>
> Michael Kay
>