- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 17 Aug 2009 21:28:27 +0100
- To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
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 -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Monday, 17 August 2009 20:29:14 UTC