A thought about requirements

This note is in reaction to what I feel is a misplaced spirit in this  
group.

I do not have the numbers to hand, but my estimation is that in the  
'rules market', it would not surprise me if the 'production rule'- 
based technology owned 95% of the market. But you would not know that  
watching the traffic on this list.

By ignoring the PRR side of the side this group risks making itself  
irrelevant.

Rather than frame the requirements in terms of horn logic vs full 1st  
order vs etc. I think that it would be better to focus on the  
application needs of rules.

For example, I can see rules being used to

1. express policies
2. express contracts
3. express business logic
etc.

I am sure that there are many more of course, these are the areas I  
have an interest in.

A focus on expressing policies, contracts would result in a totally  
different approach to developing the RIF. For example, policy  
languages span a range between trivial (WS-Policy) and requiring  
modal operators (REI).
Contracts tend to be about the rights and responsibilities of the  
parties.
(Note: I *am* thinking about executable contracts: think SLAs for Web  
services.)
Business logic is often in the form of "In this situation, do that".

If we followed such an approach, instead of asking questions about  
extensibility, multiple semantics etc. we would be asking "what does  
it take to address this need", where need is an application need not  
a technology need.

The current requirements WIKI page does not reflect this. Instead it  
attempts to synthesize the gestalt of the groups current thinking.  
That is what I am addressing here.

Frank

Received on Sunday, 28 May 2006 17:15:25 UTC