Bug #6260
closed![Author: John Ulric](https://www.gravatar.com/avatar/e071177fac4f4724360eca8039c44cff?rating=PG&size=50&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
![Assignee: Michael Kay](https://www.gravatar.com/avatar/db6526d63053f09b62e52c2da8b2230a?rating=PG&size=22&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
Operator || and fn:concat are not exactly equivalent
100%
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
Updated by Michael Kay 9 months 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.
Updated by Michael Kay 9 months ago
Test cases op-concat-21, -22, -23 added to QT4 demonstrate the problem.
Updated by John Ulric 9 months ago
Thank you, Michael. The knot in my head starts to loosen. :-)
Updated by Michael Kay 9 months 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.
Updated by O'Neil Delpratt 9 months 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