- From: Stan Devitt <stan.devitt@gwi-ag.com>
- Date: Wed, 24 May 2006 08:38:59 +0200
- To: 'Paula-Lavinia Patranjan' <paula.patranjan@ifi.lmu.de>, public-rif-wg@w3.org
- Cc: Frank McCabe <frank.mccabe@us.fujitsu.com>
Is there any particular reason we are not explicitly mentioning an abstract syntax as either a requirement or a principle in addition to a human readable and exchange syntax? I don't quite see it being implied by the other two, and it usually makes the design and implementation process a whole lot easier. Stan Devitt -----Original Message----- From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Paula-Lavinia Patranjan Sent: Tuesday, May 23, 2006 4:38 PM To: public-rif-wg@w3.org Cc: Frank McCabe Subject: [RIF] Current list of requirements and design principles for RIF ... ---------------------------------------------------------------------------- --------------------------------- DRAFT -- RIF REQUIREMENTS AND DESIGN PRINCIPLES List of design principles for RIF --------------------------------- 1. Syntax * An human legible syntax * A syntax for exchange (e.g. XML or RDF) 2. Abstractions for reusability and maintainability * Support for modules and other structuring/abstraction mechanisms (e.g. capability to bundle actions that are complex or used frequently into procedures -- in case of reactive or ECA rules) 3. Language coherency * Coherency refers to a couple of sub-principles to be followed so as to obtain a uniform and easy to use RIF. Rules are made of components such as the body and head of deductive rules and the event part, condition part and action part of ECA rules; to gain coherency, these rule components should follow same paradigms. Moreover, some components (such as the body of deductive rules and the condition part of ECA rules) have same design goals and thus they shouldn't be specified by using different RIF component languages. ...
Received on Wednesday, 24 May 2006 06:39:18 UTC