RE: MS-FO-LC1-033: Allow concat strings to be sequences

Thanks for the comment. 

I see that allowing xs:string* would break XPath 1.0
backwards-compatibility since the backwards-compatible behaviour would
not be triggered anymore.

I still think it would be the right, unless we see fn:concat as a XPath
1.0 relict only.

Best regards
Michael

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Tuesday, July 01, 2003 2:15 AM
> To: Michael Rys
> Cc: public-qt-comments@w3.org
> Subject: Re: MS-FO-LC1-033: Allow concat strings to be sequences
> 
> Michael Rys wrote:
> > 7.4.1 fn:concat: Why has $op to be xs:string? And not xs:string*.
> > Allow xs:string* and concatenate them as well (see 7.4.2 remark that
> > only holds if fn:concat(("a", "b")) would be a valid expression).
> >
> > Examples: fn:concat(("a","b")) should be "ab".
> > fn:concat(("a","b"),"c") should be "abc".
> 
> The string-join() function provides the facility for concatenating
> strings in a sequence, and is a lot more powerful than concat() for
> doing so.
> 
> If this change were made, the backwards compatibility conversion rules
> would also have to change. In XPath 1.0, given:
> 
>   concat('foo: ', foo)
> 
> you would get 'foo: ' concatenated with the string value of the
> *first* of the <foo> elements, rather than the string values of the
> <foo> elements all concatenated together. I think that changing the
> backwards compatibility conversion rules to handle the case where the
> type of the argument is xs:string* would cause problems elsewhere --
> for example it would prevent string-join() from working properly in
> backwards compatibility mode.
> 
> Cheers,
> 
> Jeni
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Tuesday, 1 July 2003 14:03:31 UTC