This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29184 - Modify fn:string-join to accept xs:anyAtomicType* instead of xs:string*
Summary: Modify fn:string-join to accept xs:anyAtomicType* instead of xs:string*
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Proposed Edited Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2015-10-08 14:38 UTC by Josh Spiegel
Modified: 2016-03-22 10:07 UTC (History)
1 user (show)

See Also:


Description Josh Spiegel 2015-10-08 14:38:32 UTC

We should modify fn:string-join to accespt xs:anyAtomicType* instead of xs:string*


  string-join(1 to 4, " ") => “1 2 3 4”

The function should also specify that each value in the sequence is cast to xs:string.
Comment 1 Abel Braaksma 2015-10-16 15:30:17 UTC
While we're at it, does it make sense to also update the second argument to allow for xs:anyAtomicType?, or xs:string??

It simplifies writing (a variant of):

  string-join(1 to 4, if(@separator) then @separator else '')


  string-join(1 to 4, @separator)

assuming the second argument follows from string($arg2), so the empty sequence as in string(()), will return the empty string.
Comment 2 Michael Kay 2015-10-16 15:56:54 UTC
Our general approach has been to distinguish "input" arguments from "control" arguments. Input arguments are likely to originate from the source document being queried, control arguments are likely to originate from the query logic itself. Input arguments generally allow an empty sequence, control arguments do not. I think that the separator is correctly treated as a control argument; a use case such as yours where it derives from the source document is unusual. Therefore I think it the type should remain exactly-one.
Comment 3 Michael Kay 2015-10-16 16:47:12 UTC
Note also, the use case in comment 1 can be done with

string-join(1 to 4, string(@separator))

If you want a concise way of using a different default separator you can write

string-join(1 to 4, (@separator, '#')[1])
Comment 4 Abel Braaksma 2015-10-16 18:02:50 UTC
(In reply to Michael Kay from comment #2)
> Our general approach has been to distinguish "input" arguments from
> "control" arguments. 

Ok, makes sense. I wasn't aware of that distinction.

I'm aware of the similar ways of writing the if-statement, I think my original idea came primarily from the feeling of "what is sauce for the goose is sauce for the gander"... 

But that can equally well apply to the argument that any control argument should be exactly-one.
Comment 5 Michael Kay 2015-10-27 15:28:54 UTC
The proposal (changing the first argument only) was today accepted.
Comment 6 Josh Spiegel 2015-12-14 23:46:40 UTC
I happened to notice that this is not in the draft yet.  Apologies if you were already aware of this.
Comment 7 Michael Kay 2015-12-16 12:13:28 UTC
Thanks for the reminder. It had indeed slipped under the radar. Now done.