Hi!
>What I mean is way to implement the ideas Alan is talking
>about here, in a flexible and extensible way is to use XML
>definitions for everything, with associated DTDs for the
>core Jess definitions, AND user-defined DTDs for the
>"some-other-language-here" constructs, for example.
>You could then use style sheets (or other logic code)
>for, among other things, for translation and compilation
>of the "some-other-language-here" constructs.
In my system I defined an XML representation of deftemplates, facts and
(simple) rules.
Consider the following UML Package which is defined using a rather simple
DTD.
<Package name="HR" stereotype="subsystem">
<Class name="Person">
<Attribute name="number" type="long" constraint="primary-key"/>
<Attribute name="name" type="String"/>
<Attribute name="salary" type="double"/>
<Attribute name="deptno" type="long"/>
<Attribute name="dname" type="String"/>
<Attribute name="location" type="String"/>
</Class>
</Package>
Based on such a definition deftemplates can be generated automatically.
Facts are represented as follows:
<Literal name="HR-Person">
<Term name="number" type="long" constraint="primary-key">2</Term>
<Term name="name" type="string">Barnekow</Term>
<Term name="salary" type="double">8000</Term>
<Term name="deptno" type="long">4</Term>
<Term name="dname" type="String">R&D</Term>
<Term name="location" type="String">Stuttgart</Term>
</Literal>
The notions used for representing facts are based on first order logic.
This is due to historic reasons. I was thinking about using UML notions
throughout.
Simple Jess rules can be represented as follows:
<Program name="HR-Person">
<Procedure name="HR-Person">
<Head>
<Literal name="HR-Person">
<Term name="number" type="long" kind="var">V1</Term>
<Term name="name" type="String" kind="var">V2</Term>
<Term name="salary" type="double" kind="var">V3</Term>
<Term name="deptno" type="long" kind="var">V4</Term>
<Term name="dname" type="String" kind="var">V5</Term>
<Term name="location" type="String" kind="var">V6</Term>
</Literal>
</Head>
<Body>
<Literal name="scott-emp">
<Term name="empno" type="long" kind="var">V1</Term>
<Term name="ename" type="String" kind="var">V2</Term>
<Term name="sal" type="double" kind="var">V3</Term>
<Term name="deptno" type="long" kind="var">V4</Term>
</Literal>
<Literal name="scott-dept">
<Term name="deptno" type="long" kind="var">V4</Term>
<Term name="dname" type="String" kind="var">V5</Term>
<Term name="loc" type="String" kind="var">V6</Term>
</Literal>
</Body>
</Procedure>
</Program>
Semantically, this rule defines a database view.
I've designed and implemented a very flexible mechanism for generating Jess
constructs from XML and vice-versa. I found that rather useful for a couple
of reasons:
- rules and templates can be stored and retrieved in a very structured way,
e.g. in a repository
- communication between different systems is facilitated
- other meta-data can be associated with the constructs
- ...
Greetings
Thomas
________________________________
Dipl.-Inform. Thomas Barnekow
phone: +49 (0) 172 / 7126018
email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
