Binary comparisons

[ChristianGruen]

It seems confusing to me that deep-equal & atomic-equal return different results than eq for binary types:

let $hex := xs:hexBinary(''), $base64 := xs:base64Binary('')
return (
  (: false :) deep-equal($hex, $base64),
  (: false :) atomic-equal($hex, $base64),
  (: true  :) $hex eq $base64
)

The rules say:

fn:deep-equal

If both $i1 and $i2 are instances of xs:hexBinary or xs:base64Binary, $i1 eq $i2 returns true.

This can be interpreted in two ways, but it seems to mean that $i1 and $i2 need to have the same type?

fn:atomic-equal

One of the following conditions is true:
$value1 and $value2 are both instances of xs:hexBinary.
$value1 and $value2 are both instances of xs:base64Binary.

op:binary-equal

op:binary-equal(
  $value1	as (xs:hexBinary | xs:base64Binary),	
  $value2	as (xs:hexBinary | xs:base64Binary)	
) as xs:boolean

The function returns true if $value1 and $value2 are of the same length, measured in binary octets, and contain the same octets in the same order. Otherwise, it returns false.

As atomic-equal(xs:double(3), xs:float(3)) returns true, I would also expect true for binary items with the same contents.

Related (for numbers): #986

[michaelhkay]

No, there's no requirement for them to have the same type. The spec for atomic-equal spells this out more pedantically, but the intended effect is the same.

[ChristianGruen]

No, there's no requirement for them to have the same type.

I guess we would then need to change the rules for fn:atomic-equal to:

$value1 and $value2 are both instances of xs:hexBinary or xs:base64Binary.

[ChristianGruen]

Some tests may need to be fixed as well. This one…

https://github.com/qt4cg/qt4tests/blob/0eaecb9dba80c1b95c53fff21d03df8ca94656d4/fn/atomic-equal.xml#L311

…returns false for:

atomic-equal(
  xs:hexBinary("ff"),
  xs:base64Binary(xs:hexBinary("ff"))
)

[michaelhkay]

Ah, yes, I'm now recalling what happened here. Sorry about my incorrect answer earlier.

In 3.1, op:same-key was defined like this:

All of the following conditions are true:

• $k1 is an instance of xs:boolean, xs:hexBinary, xs:base64Binary, xs:duration, xs:QName, or xs:NOTATION
• $k2 is an instance of xs:boolean, xs:hexBinary, xs:base64Binary, xs:duration, xs:QName, or xs:NOTATION
• fn:deep-equal($k1, $k2)

deep-equal in 3.1 was defined in terms of eq, and eq was defined in terms of op:hexBinary-equal() or op:base64Binary-equal(). B64 and HEX were not mutually comparable using eq, and were therefore not equal under deep equal or op:same-key.

I believe that we made a conscious decision to change eq in 4.0 so that B64 and HEX were mutually comparable; this is reflected by the fact that there is now a single supporting function, op:binary-equal. However there are no change sections to reflect this change; also, the following rule should have been updated:

5. If the two operands are instances of different primitive types (meaning the 19 primitive types defined in [Section 3.2 Primitive datatypes], then:

I believe that we also made a conscious decision NOT to change op:same-key / fn:atomic-equal, on the grounds of backwards incompatibility: maps that contain instances of both types would work differently.

I would now be inclined to make B64 and HEX mutually comparable under all three functions, despite the incompatibility.

[ChristianGruen]

I would now be inclined to make B64 and HEX mutually comparable under all three functions, despite the incompatibility.

Thanks. I agree: it is improbable that old code needs to be rewritten due to the proposed change.