RE: ACTION-313: builtins

 

 

Hello,

 

I have the following comments about the built-in functions and operators
proposed by Paula in the
http://www.w3.org/2005/rules/wg/wiki/List_of_functions_and_operators
page.

 

Generally speaking, I think that using those functions is interesting
when:

*         The underlying data model is XML-XSD.

*         The functions are so wildly spread (arithmetic) to be able to
represent their corresponding operators in other languages, although it
may arise potential difference of semantics (overflow...).

 

About the comparison operators, it lacks the '<=' and '>=' in the XPath
library. 

 

Concerning the function on String, I wonder if we should add concat,
encode-for-uri, iri-to-uri and escape-html-uri in the core. 

Could we limit the selection to function without any collation
attribute?

The match function may be difficult to code (regular expression) if
there is no equivalent in the library of the target language.

 

About the dates and times operator, useful for ECA rules and potentially
for PR rules (extended with chronicle), could they be transferred into a
sub-dialect? Their implementation is not so convenient too, except if it
exists a time and date library for the targeted language.

 

Finally, maybe some functions of XPath DM might be interesting for core
http://www.w3.org/TR/xpath-datamodel, in particular some XML accessors
coming from http://www.w3.org/TR/xpath-datamodel/#accessors?

 

Regards. Philippe.

 

 

 

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Axel Polleres
Sent: Tuesday, June 12, 2007 2:17 PM
To: Igor Mozetic
Cc: public-rif-wg@w3.org
Subject: Re: ACTION-313: builtins

 

 

Igor Mozetic wrote:

> 

> Hi,

> 

> I have the action to propose adding/removing builtins functions and 

> operators

> to
http://www.w3.org/2005/rules/wg/wiki/List_of_functions_and_operators

> In addition to what Paula already proposed, I think we need also the

> following (functions that are not easily derivable from the rest):

> 

>    6.2 Operators on Numeric Values

>        6.2.5 op:numeric-integer-divide

>        6.2.6 op:numeric-mod

>    6.4 Functions on Numeric Values

>        6.4.1 fn:abs

>        6.4.2 fn:ceiling

>        6.4.3 fn:floor

>        6.4.4 fn:round

>        6.4.5 fn:round-half-to-even

>    7.2 Functions to Assemble and Disassemble Strings

>        7.2.1 fn:codepoints-to-string

>        7.2.2 fn:string-to-codepoints

> 

> We also need operations on lists/sequences, but I'm not sure if

> we want to completely adopt the XQuery and XPath operators.

> In addition to the basic operations on lists, we need the aggregates:

> 

> 15 Functions and Operators on Sequences

>    ....

>    15.4 Aggregate Functions

>        15.4.1 fn:count

>        15.4.2 fn:avg

>        15.4.3 fn:max

>        15.4.4 fn:min

>        15.4.5 fn:sum

> 

 

Re: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0003.html

and

     http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0004.html

 

... I think this needs some thought, especially something like 

aggregates! Aggregates can also be (and are by implemented rule 

systems!) on predicate extensions instead o lists.

  Also, we do not have a datatype for lists yet, do we? (mainly asking 

because I might have missed that on the second day of the f2f in
case...)

 

axel

 

-- 

Dr. Axel Polleres

email: axel@polleres.net  url: http://www.polleres.net/