- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Fri, 27 Feb 2009 16:40:23 -0500
- To: Chris Welty <cawelty@gmail.com>
- Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
My preference here would be (3) below. If not that then we could drop the fixed arity requirement for externals. I don't see it as a change that will require us to redo the LC. michael On Fri, 27 Feb 2009 15:32:42 -0500 Chris Welty <cawelty@gmail.com> 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> > > >
Received on Friday, 27 February 2009 21:41:02 UTC