W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2009

Re: ISSUE-92: n-ary builtins

From: Axel Polleres <axel.polleres@deri.org>
Date: Mon, 16 Mar 2009 21:57:34 +0000
Message-ID: <49BECB4E.50608@deri.org>
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.


> 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, 
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Monday, 16 March 2009 21:58:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:54 UTC