Summary of conclusions from UC session Dec 05

In Wiki format, but I cannot edit the Use Cases wiki page, and I have to 
go...

Christian

* Requirements for covering features of existing rule languages or engines (e.g. handling uncertainty) need use cases only for illustration and prioritization purposes:
	* For the purpose of phase one, we need to know the (future) requirements mostly for designing the extensibility mechanism of the RIF;
	* The use cases themselves will be needed mostly to prepare phase 2;
* We need interchange-specific scenarios, illustrating cases where, for instance:
	* The rules may behave or be used differently on either ends of the interchange, e.g.
		* allowing downgraded modes (e.g. executing uncertain rules by a crisp-only receiving engine in Vassili's use case);
		* data access (e.g. data about the status of a customer and the content of his shopping cart are found in the same location if a pricing rule is executed locally, and in different places if remotely, cf csma's short use case);
		* ...
	* Ownership/Confidentiality issues impact the interchange (e.g. in some case the rules are sent for remote evaluation because access to the data is restricted - see Paula's use case ; in other cases all or part of the rules may be confidential, etc);
	* Data may/need be interchaned along with rules and/or instead of rules (as in Harold's example);
	* Specific non-functional factors may impact the design fo the RIF (e.g. real-time unmarshalling of the rules in Paul's stock trading example). Scalability, security issues, ...;
	* The purpose of interchanging rules is not directly executing them (e.g. visualisation as in Paula's example; validation, edition etc), or not directly within an "end-application" (e.g. Paul's comment about executing rulesets from different sources to compare their behaviours);
	* There exist another standard-based solution than RIF (like Harold's use case, where RDF could be used). Why RIF is prefered must of course be explained;
* We miss use cases for interchange between different classes of platform ("strong" interoperability).