- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Thu, 10 Jan 2008 14:29:13 -0500
- To: Christian de Sainte Marie <csma@ilog.fr>
- Cc: RIF WG <public-rif-wg@w3.org>
> Michael Kifer wrote: > >> > >>How do commonly used implementations of basic logic rule languages > >>handle the case [...] > > > > Usually they issue an error. But they do not have a model theory for it, > > Which is why I am somewhat insistant that we should consider doing what > I call "not giving a semantics to error" and that Bijan calls (certainly > more appropriately, since you understand him :-): "support builtins > syntactically but say that their semantic on error is implementation > dependent" [1] (Bijan: yes, this is what I propose as a third alternative). What is "semantics on/of error" and what is "error"? I propose to give semantics without errors (pun intended) and then deal with "errors" at the compliance level. > > and they do not write a document for W3C saying "this is THE semantics of > > ...". > > But we do not _have_ to write a document for W3C saying "this is THE > semantics of..."! > > We have to write for W3C a "technical specifications of [a rule] > interchange format, suitable for implementers of rule engines and rule > language translation software", where "this format (or language) will > function as an interlingua into which established and new rule languages > can be mapped, allowing rules written for one application to be > published, shared, and re-used in other applications and other rule > engines". We have to give semantics to the BLD dialect. Did we agree to this? If not, then we have to go back 1.5 years and start from scratch. > To me, this seems perfectly compatible with not supporting a specific > semantics for error if there is not one that is prevalent in current > implementations. > > This is why I insist that we should consider alternative (c) in addition > of (a) and (b): > > (c) to support builtins (and evaluated functions and predicates in > general) syntactically, and semantically within their domains of > definition, but to leave their semantics of error implementation > dependent. (Maybe requiring that the error not be processed silently, > though). Christian, you are missing something very trivial, but fundamental. Did we agree to give a model theory to BLD? If we did, then we have to give it. A model theory is incompatible with what you call option (c). As is, the above paragraph is not a model theory but a model-theoretic gobbledeegook. If you can turn it into something formal - fine. If not, let's not waste time. > I understand that alternative (c) would not work if we were chartered to > specify a rule language, but that is one of the benefits of having to > specify "only" an interchange format that it works for us! What do you mean by "works for us"? Who is "us". I may be misinterpreting you, but it seems that you are proposing to throw out most of what has been done and go back some 18 months. --michael > > Christian > >
Received on Thursday, 10 January 2008 19:29:31 UTC