Project

Profile

Help

Bug #6260

closed

Operator || and fn:concat are not exactly equivalent

Added by John Ulric about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
XPath conformance
Sprint/Milestone:
-
Start date:
2023-11-22
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
12, trunk
Fix Committed on Branch:
12, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

Probably not the most urgent problem admittedly ;-) but I've been trying to wrap my head around XPath Atomization § 2.4.2 and Function Conversion Rules § 3.1.5.2 in more detail and was wondering about the following effect with fn:concat and the string concatenation operator ||.

§ 3.6 says: In XPath 3.1, $a || $b is equivalent to fn:concat($a, $b).

With Saxon HE 12.3, || and fn:concat do not seem to be exactly equivalent:

let $a:=(1,2), $b:=(3,4) return concat($a, $b)
→ XPTY0004  The first argument of concat() does not satisfy the cardinality constraints
let $a := (1,2), $b:=(3,4) return $a || $b
→ 1234

Is this maybe an artifact of fn:concat being the only varargs function? Or is there a part of the spec that I'm missing? Or is it a missing detail in the spec? Or a Saxon issue?

fn:string-join, eg, behaves as I would have expected:

let $a:=(1,2,3) return string-join($a, "-")
→ 1-2-3
let $a:=[1,2,3] return string-join($a, "-")
→ 1-2-3

Thanks, John

Actions #1

Updated by Michael Kay about 1 year ago

  • Tracker changed from Support to Bug

Thanks for pointing this out.

It seems that for concat() we have custom logic for the type checking that treats 3.1 and 4.0 differently, so that we enforce the 3.1 rules unless you explicitly enable 4.0 behaviour. But for the operator || we are apparently invoking the 4.0 behaviour of concat() unconditionally. The 4.0 rules allow arguments to be any sequence, so concat($x, $y, $z) and concat(($x, $y, $z)) become equivalent.

Actions #2

Updated by Michael Kay about 1 year ago

Test cases op-concat-21, -22, -23 added to QT4 demonstrate the problem.

Actions #3

Updated by John Ulric about 1 year ago

Thank you, Michael. The knot in my head starts to loosen. :-)

Actions #4

Updated by Michael Kay about 1 year ago

  • Category set to XPath conformance
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Applies to branch trunk added
  • Fix Committed on Branch 12, trunk added
  • Platforms .NET, Java added

Now fixed.

In the course of fixing it I also removed the 4.0 variadic version of fn:codepoints-to-string(), a change that was proposed for the 4.0 spec but not confirmed.

Actions #5

Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 12.4 added

Bug fix applied in the Saxon 12.4 maintenance release

Please register to edit this issue

Also available in: Atom PDF