W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2008

Re: model theory of error

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Tue, 08 Jan 2008 11:14:15 -0500
To: Christian de Sainte Marie <csma@ilog.fr>
Cc: RIF WG <public-rif-wg@w3.org>
Message-ID: <26457.1199808855@cs.sunysb.edu>

How do you define an error independently of the evaluation strategy?
What does it mean to say that "RIF does not mandate any 
specific behaviour"? What is "behavior" exactly, if RIF (at least BLD) does
not define any evaluation strategy?

> Michael Kifer wrote:
> > Last Tuesday we were unable to resolve the issue of builtin functions
> > because we could not decide on their semantics. The problem is that builtin
> > functions are partial and are supposed to return an error if given wrong
> > arguments.
> For the strict purpose of rule interchange, do we need to give semantics 
> to undefined items such as evaluated functions or predicates with 
> out-of-domain arguments?
> Of course, if there were a standard semantics and/or expected behaviour, 
> it would make sense for RIF to use it.
> But I understand that it is not the general case: so, wouldn't imposing 
> a specific behaviour (e.g. as proposed by Michael) hamper interchange 
> between rule languages that have a different behaviour (such as failing 
> or throwing an exception, which is probably quite a common behaviour in 
> current rule languages)?
> Do we need anything more than specifying that RIF does not mandate any 
> specific behaviour for handling undefined items (and leave it to the 
> implementations to decide/know what to do about it)?
> Or specifying that such cases must be handled as an error (leaving it to 
> each implementation to decide or know how to handle the error), if we 
> want to make sure that using RIF for rule interchange will not cause 
> invisible unexpected consequences.
> In addition, that would save us the burden of inventing a model theory 
> of error :-)
> Christian
Received on Tuesday, 8 January 2008 16:14:22 UTC

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