- From: Axel Polleres <axel.polleres@deri.org>
- Date: Fri, 27 Feb 2009 22:15:34 +0000
- To: Chris Welty <cawelty@gmail.com>
- CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
slight problem for 3 if feasible (BLD editors need to agree, but Michael's mail seems to indicate green light?) Chris Welty wrote: > > The basic issue is that BLD (and core) require all predicates and > functions to have a fixed arity, but in DTB we reuse many xpath/xquery > functions and predicates, and there are several that do not have a fixed > arity (e.g. concat). In DTB, the treatment of these operators is > unclear: > > "numbering the different versions of the respective built-ins and > treating the unnumbered version as syntactic sugar, i.e. for instance > instead of External( func:concat2( str1, str2) ) and External( > func:concat3( str1 str2 str3 ) ) we allow the equivalent forms External( > func:concat( str1, str2) ) and External( func:concat( str1 str2 str3 ) )." > > Does this mean that BLD should allow rulesets to use concat with any > arity, or does it mean that for the purposes of DTB we write concat as a > shortcut for whichever (concat2, concat3, etc) is appropriate? > > Possible solutions: > > 1) Make it clear this is only for the purposes of writing DTB, and that > all rulesets must use a fixed arity function/predicate > > 2) Allow for some preprocessing step in RIF implementations where > functions like concat are replaced with their fixed-arity equivalents > > 3) Change BLD to allow for arbitrary arity functions and predicates. I > can find no formal resolution to make preds/funs fixed arity, however it > would be a major change to a LC document (BLD). At the last telecon, no > one was opposed to this change on technical grounds, only because of the > LC status. > > </chair> > I prefer option 1. > <chair> > > > -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Friday, 27 February 2009 22:16:29 UTC