A completely different alternative for the rules language can be based
on an existing language/runtime (say Java based). However the approach
taken by Java for specifying rules (see Jess,JSR) is very "Constraint
Logic Programming' type - which I beleive may be an overkill for the
OPES framework. Other rules-based frameworks are similarly very complex.
What we need is just a means of scripting out the rules - P may work!
Also, after somewhat freezing the charter (atleast in concept) about the
'P' applicability - limiting the usage to the OPES administrator (as
opposed to rules authored by client or content provider ) ; 'P' seems to
have the core stuff. May require some enhancements and more
complementary specifications for interfacing things and so on..
I would go with (b) or (c) while preferring (c) since it is less work
;-)
regards
Geetha
Abbie Barbir wrote:
MArkus,
new insights are comming as we speak.
but as I said I can live with the other options
abbie
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Tuesday, July 13, 2004 4:56 PM
To: OPES Group
Subject: Re: Strawman OPES Charter
Abbie Barbir wrote:
Just to make sure: which of the following you consider essential:
a) forget about P choice, start from scratch, write a
formal "language requirements" document, then select
among
IRML, P, and possibly other candidates.
b) confirm past P choice, but write a "language
requirements"
document or section, before proceeding with polishing P
c) confirm P choice, and do not write a "language
requirements" document/section
well, I go for option a) to be frank. However, I can live
with b) or
c) if the WG wants that.
Are there any new insights or developments that came up after our
earlier discussions we had on "P" and other approaches? If not, I
don't want to re-iterate the discussions we already had.
-Markus