Re: Action Item QT4CG-004-02: DN to make a proposal for deep-equal-safe for future discussion ( Re: Draft minutes for QT4CG meeting 004, 2022-09-27)

A couple of comments:

(a) I have proposed (somewhere) changing the semantics of numeric comparisons using eq to convert both values to decimal rather than to double (as op:same-key does). But of course NaN=NaN would remain false. This function could take advantage of this.

(b) The function inherits most of the weaknesses of fn:deep-equal. For example it's clearly a design mistake that comments and processing instructions are ignored without merging their adjacent sibling text nodes; the rules for comparing typed and untyped content are also pretty unusable, as is the treatment of whitespace. It's also unfortunate that fn:deep-equal gives a different result from serializing into XML canonical form and comparing the serializations. It's hard to know whether this matters without considering use cases for this new function; but if we're defining a new function, then we ought to fix the known faults in the old one.

In practice I don't think it's possible to define a set of rules for comparing node trees that satisfies a wide range of use cases without parameterising it. Even the rules for canonical XML are parameterized (IIRC) in regards to their handling of namespaces and whitespace.

So it boils down to: what are the use cases that this new function is designed for?

Michael Kay


> On 28 Sep 2022, at 04:17, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 27, 2022 at 9:42 AM Norm Tovey-Walsh <norm@saxonica.com <mailto:norm@saxonica.com>> wrote:
> 
> 
> Draft Minutes
> 
> Summary of new and continuing actions [0/7]
> 
>      * [ ] QT4CG-002-01: NW to incorporate email feedback and produce new
>        versions of the process documents.
>      * [ ] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid
>        line breaks on - characters.
>      * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
>        diversity in the group
>      * [ ] QT4CG-004-01: MK (with DN and RD) to draft a new proposal for
>        variadic functions
>      * [ ] QT4CG-004-02: DN to make a proposal for deep-equal-safe for future
>        discussion
>      * [ ] QT4CG-004-03: MK to draft a pull request implementing
>        fn:intersperse
>      * [ ] QT4CG-004-04: DN to open an issue for the inverse of
>        fn:intersperse
> 
> 
> The description of the function fn:deep-equal-safe() is in a pdf file that can be found here:
> 
> https://github.com/dnovatchev/FXSL-XSLT2/blob/master/fn-deep-equal-safe.pdf <https://github.com/dnovatchev/FXSL-XSLT2/blob/master/fn-deep-equal-safe.pdf>
> 
> Note: this document is essentially a compilation from the FO 3.1 of:
>       op:same-key  (https://www.w3.org/TR/xpath-functions-31/#func-same-key <https://www.w3.org/TR/xpath-functions-31/#func-same-key>),  and 
>       fn:deep-equal (https://www.w3.org/TR/xpath-functions-31/#func-deep-equal <https://www.w3.org/TR/xpath-functions-31/#func-deep-equal>)
> 
> Special care was taken to substitute the fn:deep-equal semantics that either results in raising an error, or in possible intransitivity or context-dependency. All such behavior has been substituted with the corresponding behavior from op:same-key, which the 3.1 Spec claims to be: "deterministic, context-independent, and ·focus-independent", etc.
> 
> More specifically, to achieve this:
> 
> No errors are raised, instead false() is returned
> 
> Strings are compared without any dependency on collations (fn:codepoint-equal is used in such comparisons)
> 
> Not using eq but instead every instance of xs:double, xs:float and xs:decimal is represented exactly as a decimal number provided enough digits are available both before and after the decimal point.Unlike the eq  relation which converts both operands to xs:double values, possibly losing precision in the process, this comparison is transitive
> 
> fn:deep-equal is used in comparing values having a variety of date, time, year, month day types so that, unlike when using eq, no error is raised when comparing values of different types, but just fasle() is returned. Also, unlike when using the eq operator, this comparison has no dependency on implicit time-zone, meaning no dependency on this aspect of the dynamic context.
> 
> The goal of this function description is to serve as a starting point for discussion about possible options for fn:deep-equal.
> 
> Any comments will be appreciated.
> 
> Thanks,
> Dimitre