- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 16 Mar 2009 21:57:34 +0000
- To: Dave Reynolds <der@hplb.hpl.hp.com>
- CC: Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Dave Reynolds wrote: > I can live with any of these options. > > I've a mild preference for 3b (and in general 3*) over 1*. > [Jena already has variable arity external predicates and it would be > slightly easier to do the translation if that was available in RIF.] despite regrets for tomorrow, +1 for 3b. Axel > Dave > > Chris Welty wrote: >> >> Lets try to find an option we can all live with from among the >> following on the upcoming telecon: >> >> Current status: >> >> Of the options discussed so far, the following remain: >> >> 1. Make it clear this is only shorthand for the purposes of writing >> DTB, and that all rulesets must use a fixed arity function/predicate >> >> 1a. specify one rather than n different functions. So, in the case of >> concat we would only have a binary string concatenation function. >> Clearly all the others can be built from this base case. >> >> 3a. Remove all the well-formedness requirements. The same symbol can >> have several arities, can be a pred, func, and an individual in >> different contexts. >> >> 3b. To keep the separation between preds, funcs, and individuals, but >> pred, func, external symbols can have multiple arities. >> >> 3c. To keep things as before, but for external symbols to allow >> multiple arities (and maybe even allow them to be funcs and preds in >> different contexts). >> >> >> Description: >> 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? >> >> >> > > > > -- 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, 16 March 2009 21:58:31 UTC