Re: DTB: Problem/Erratum for DTBin function string-join

i think using lists is a cleaner solution in general

On Mon, 17 Aug 2009 21:28:27 +0100
Axel Polleres <axel.polleres@deri.org> wrote:

> Hi all,
> 
> While working on the all-builtins use case, I realize a slight 
> error/problem in DTB now with the function:
> 
> func:string-join(...)
> 
> its xpath/xquery counterpart fn:string-join(...)
> 
> takes two arguments:
> - a sequence of strings
> - a "separator" string
> 
> now I realize - since this function was introduced when we didn't heva 
> lists in RIF yet, that we seem to have expected a "flattened" list as 
> input, i.e. we give the schemas
> 
> ( ?arg1 ?arg2; func:string-join(?arg1 ?arg2 ) )
> 
> ( ?arg1 ?arg2 ?arg3; func:string-join(?arg1 ?arg2 ?arg3 ) )
> 
> ...
> 
> ( ?arg1  ?arg2 ... ?argn; func:string-join(?arg1 ?arg2 ... ?argn ) )
> 
> 
> Anyways, the semantics is defined in terms of fn:string-join, which 
> didn't work so far, but only works with a small fix, i.e. interpreting 
> the first n-1 arguments as the sequence argument of the CPAth/Xquery 
> fn:string-join function. "Historically" this is IMO what we meant, as 
> there was no lists.
> 
> Thus, I see two options for fixing this:
> 
> a) stick with the flattened version, interpreting the first n-1 
> arguments as the sequence argument of the CPAth/Xquery fn:string-join 
> function and the last argument as the separator string.
> 
> b) make the function with a fixed arity of 2,  the domain of the first 
> argument being a list of strings and the second argument the separator 
> string.
> 
> I implemented option a) now, since it is the "least intrusive" change to 
> the current doc, see
> 
> http://www.w3.org/2005/rules/wiki/index.php?title=DTB&diff=10665&oldid=10495
> 
> however, b) seems somehow the more natural way to proceed. The 
> disadvantage/worry I see with b) is that we might want to implement
> "emulating" sequences by lists as input in other functions as well... 
> Opinions?
> 
> Axel
> 
> 
>