[jboss-svn-commits] JBL Code SVN: r14298 - in labs/jbossrules/trunk/documentation/manual/en: Chapter-Papers and 4 other directories.

jboss-svn-commits at lists.jboss.org jboss-svn-commits at lists.jboss.org
Thu Aug 16 04:12:39 EDT 2007


Author: fmeyer
Date: 2007-08-16 04:12:38 -0400 (Thu, 16 Aug 2007)
New Revision: 14298

Modified:
   labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-How_To_Use.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Introduction.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Specification.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Papers/Section-Manners.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Performance_Tuning/Section-Performance.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Release_Notes/Section-Upgrade_tips.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Overview.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Package.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml
   labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-RuleFlow.xml
Log:
JBRULES-1088 checked spell in all manual 



Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-How_To_Use.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-How_To_Use.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-How_To_Use.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -60,7 +60,7 @@
     </example>
 
     <para>"ruleExecutionSetProvider.createRuleExecutionSet( reader, null )" in
-    the above example takes a null parameter for the propties map; however it
+    the above example takes a null parameter for the properties map; however it
     can actually be used to provide configuration for the incoming source.
     When null is passed the default is used to load the input as a drl.
     Allowed keys for a map are "source" and "dsl". "source" takes "drl" or
@@ -157,7 +157,7 @@
       <title>Globals</title>
 
       <para>It is possible to support globals with JSR94, in a none portable
-      manner, by using the propperties map passed to the RuleSession factory
+      manner, by using the properties map passed to the RuleSession factory
       method. Globals must be defined in the drl or xml file first, otherwise
       an Exception will be thrown. the key represents the identifier declared
       in the drl or xml and the value is the instance you wish to be used in

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Introduction.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Introduction.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Introduction.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -9,7 +9,7 @@
   url="http://www.w3.org/TR/2006/WD-rif-ucr-20060323/">Rule Interchange Format
   (RIF)</ulink> and the OMG has started to work on a standard based on <ulink
   url="http://ruleml.org/">RuleML</ulink>, recently Haley Systems has also
-  proposed a rule alnguage standard called RML.</para>
+  proposed a rule language standard called RML.</para>
 
   <para>It should be remembered that the JSR94 standard represents the "least
   common denominator" in features across rule engines - this means there is

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Specification.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Specification.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-JSR94/Section-Specification.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -190,7 +190,7 @@
 
           <para>The InvalidRuleSessionException should be thrown when a method
           is invoked on a RuleSession and the internal state of the
-          RuleSession is invalid. This may have occured because a
+          RuleSession is invalid. This may have occurred because a
           StatefulRuleSession has been serialized and external resources can
           no longer be accessed. This exception is also used to signal that a
           RuleSession is in an invalid state (such as an attempt to use it

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Papers/Section-Manners.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Papers/Section-Manners.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Papers/Section-Manners.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -54,7 +54,7 @@
 
           <itemizedlist>
             <listitem>
-              <para>line labelling for simple scenes by constraint
+              <para>line labeling for simple scenes by constraint
               propagation</para>
             </listitem>
           </itemizedlist>
@@ -95,9 +95,9 @@
       </itemizedlist>
 
       <para>Manners has become the de facto rule engine benchmark; however
-      it's behaviour is now well known and many engines optimise for this thus
+      it's behavior is now well known and many engines optimize for this thus
       negating its usefulness as a benchmark which is why Waltz is becoming
-      more favourable. These 5 benchmarks are also published at the University
+      more favorable. These 5 benchmarks are also published at the University
       of Texas <ulink
       url="http://www.cs.utexas.edu/ftp/pub/ops5-benchmark-suite/">http://www.cs.utexas.edu/ftp/pub/ops5-benchmark-suite/</ulink>.</para>
     </section>
@@ -146,7 +146,7 @@
       he “Assign Seating” rule description. The 'l' and the 'r' refer to the
       left and right, 's' is sean and 'n' is the guest name. In my actual
       implementation I used longer notation, 'leftGuestName', but this is not
-      practicle in a printed article. I found the notation of left and right
+      practice in a printed article. I found the notation of left and right
       preferable to the original OPS5 '1' and '2</para>
 
       <literallayout>(guest (name n1) (sex m) (hobby  h1)  )
@@ -181,13 +181,13 @@
       <para>As the introduction states, manners is a depth-first or LIFO
       example. Depth-first refers to the Conflict Resolution strategy used to
       solve the problem. OPS5 had two strategies, LEX and MEA, LEX is a chain
-      of several stratagies including Salience, Recency, Complexity:</para>
+      of several strategies including Salience, Recency, Complexity:</para>
 
       <blockquote>
         <attribution>Clips Reference Manual</attribution>
 
         <para>Every fact and instance is marked internally with a “time tag”
-        toindicate its relative recency with respect to every other fact and
+        to indicate its relative recency with respect to every other fact and
         instance in the system. The pattern entities associated with each rule
         activation are sorted in descending order for determining placement.
         An activation with a more recent pattern entities is placed before
@@ -222,7 +222,7 @@
       documented the same as the Clips ones. When Miss Manners was first
       implemented in Drools 3.0 using the Depth strategy it was not producing
       the correct result, which meant it ran forever. This paper discusses the
-      behaviour of Miss Manners with two Rule engines, Clips and Jess, and how
+      behavior of Miss Manners with two Rule engines, Clips and Jess, and how
       they make it work and how it was made to work in Drools.</para>
     </section>
 
@@ -238,7 +238,7 @@
       would fire. The execution order in this rule has little importance, but
       has a big impact in the rule "Assign Seat". The Activation fires and
       asserts the first Seating arrangement, a Path and then sets the
-      Context's state to create Activatiosn for "Assign Seat".</para>
+      Context's state to create Activation for "Assign Seat".</para>
 
       <programlisting>rule assignFirstSeat() {
   when {
@@ -318,7 +318,7 @@
       correctly fire the Activation with the last asserted Seating. With Depth
       strategy the execution is arbitrary yet Manners does correctly execute
       for Jess and Clips using the Depth strategy. Clips support, via the
-      public fourms, have said that Manners was</para>
+      public forums, have said that Manners was</para>
 
       <blockquote>
         <attribution>Clips Support Forum</attribution>
@@ -334,7 +334,7 @@
 
       <para>Early Drools 3.0 implementations, implementing Depth, would not
       work as all the Activations had the same priority and the reliance on
-      arbitrary execution meant that Seatings with lower pids where firing. A
+      arbitrary execution meant that Seating with lower pids where firing. A
       LEX style recency strategy was implemented and the benchmark worked
       correctly. This leaves the question how does Jess and Clips work, even
       if it is by coincidence. While I haven’t looked at Jess or Clips code
@@ -421,11 +421,11 @@
       <para>With OPS5 LEX the recency strategy says that if all compared facts
       have the same time tag then the activation with more facts wins; which
       would make sure that "Make Path" always fires before "Path Done". Clips
-      succesfully completes manners, no matter what the defined order of the
+      successfully completes manners, no matter what the defined order of the
       rules are in the rule file. If a system is not relying on recency and
       the rule definition order does not impact execution then the Rete build
       process must attach joins in such a way that propagation ensures that
-      most complex rules activate last - a kind of inbuilt compexity strategy,
+      most complex rules activate last - a kind of inbuilt complexity strategy,
       however this is not documented; thus with LIFO the first created
       Activation will fire last. When manners is executed in CLIPS with
       breadth strategy, it may result in an infinite loop if path_done is
@@ -514,20 +514,20 @@
       </listitem>
     </itemizedlist>
 
-    <para>All the above are external optimisations, so easily detected and the
-    results made void. However its also possible to optimise internally; this
-    can be sean from the Leaps algorithm; which Drools has an expiremental
+    <para>All the above are external optimizations, so easily detected and the
+    results made void. However its also possible to optimize internally; this
+    can be sean from the Leaps algorithm; which Drools has an experimental
     implementation of. Manners is brute force stress test of the cross product
     speed of various joins. Leaps avoid full cross product testing by only
     attempting the leading join, so where as Rete would create hundreds of
     Activations leaps only creates one - this gives orders of magnitudes speed
     increases. Modern Rete based Rule Engines are starting to analyse networks
-    and apply this type of optimisation, whether its a leaps style lazy
-    evaluation or a pre-compilation optimisation to avoid erroneous joins.
-    Drools ReteOO does not currently make these types of optimisations
-    although pre-compilation optimisations will be researched in the next
-    release. These optimisations have made the Miss Manners benchmark
-    redundant and the results form a system that optimises in this manner
+    and apply this type of optimization, whether its a leaps style lazy
+    evaluation or a pre-compilation optimization to avoid erroneous joins.
+    Drools ReteOO does not currently make these types of optimizations
+    although pre-compilation optimizations will be researched in the next
+    release. These optimizations have made the Miss Manners benchmark
+    redundant and the results form a system that optimizes in this manner
     should be considered void. This view is also put forward by James Own who
     publishes the 2000-2005 Benchmarks, <ulink
     url="http://www.kbsc.com/Performance2000-2005.xls">http://www.kbsc.com/Performance2000-2005.xls</ulink>:</para>

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Performance_Tuning/Section-Performance.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Performance_Tuning/Section-Performance.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Performance_Tuning/Section-Performance.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -11,7 +11,7 @@
   should not need to read this chapter in detail.</para>
 
   <para>Note that for someone who is using a rule engine of the first time,
-  the most noticable "cost" will be the startup of the rule engine (which is
+  the most noticeable "cost" will be the startup of the rule engine (which is
   actually compiling the rules) - this problem is easily solved - simply cache
   the RuleBase instances (or the rule packages) and only update rules as
   needed (there are many ways to achieve this in your application which will
@@ -151,9 +151,9 @@
 </programlisting> Rewriting it as shown bellow will probably give you a better
       performance, as “name” is probably a more restrictive constraint than
       “department”: <programlisting>Employee (name == $aName, department == $aDepartment)
-</programlisting> (Unless you work in an organisation where there are more
+</programlisting> (Unless you work in an organization where there are more
       departments then employees, which could well be the case in a Government
-      organisation ;)</para>
+      organization ;)</para>
     </section>
 
     <para>Some other improvements are being developed for Drools in this area
@@ -296,7 +296,7 @@
     situation, this may not be an option. So what can you do when the ruleset is large and
     rewriting the rules isn't an option?</para>
     <para>The only viable option is to scale the hardware and use a different JVM. This means
-    using 64bit JVM from SUN, IBM or BEA JRockit on a machine with atleast 8Gb RAM. Depending
+    using 64bit JVM from SUN, IBM or BEA JRockit on a machine with at least 8Gb RAM. Depending
     on the ruleset, the system may need more RAM.</para>
     
   </section>

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Release_Notes/Section-Upgrade_tips.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Release_Notes/Section-Upgrade_tips.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Release_Notes/Section-Upgrade_tips.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -3,9 +3,9 @@
   <title>Upgrade tips from Drools 3.0.x to Drools 4.0.x</title>
 
   <para>As mentioned before Drools 4.0 is a major update over the previous
-  Drools 3.0.x series. Unfortunatelly, in order to achieve the goals set for
+  Drools 3.0.x series. Unfortunately, in order to achieve the goals set for
   this release, some backward compatibility issues were introduced, as
-  discussed in the maiil list and blogs.</para>
+  discussed in the mail list and blogs.</para>
 
   <para>This section of the manual is a work in progress and will document a
   simple how-to on upgrading from Drools 3.0.x to Drools 4.0.x.</para>
@@ -95,7 +95,7 @@
 
       <para>The Working Memory actions in rule consequences were also changed
       in a similar way to the change made in the API. The following table
-      sumarizes the change:</para>
+      summarizes the change:</para>
 
       <table>
         <title>Working Memory Actions equivalent DRL commands</title>

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rete_Algorithm.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -10,9 +10,9 @@
   into 2 parts: rule compilation and runtime execution.</para>
 
   <para>The compilation algorithm describes how the Rules in the Production
-  Memory to generate an efficient descrimination network. In non-technical
-  terms, a descrimination network is used to filter data. The idea is to
-  filter data as it propogates through the network. At the top of the network
+  Memory to generate an efficient discrimination network. In non-technical
+  terms, a discrimination network is used to filter data. The idea is to
+  filter data as it propagates through the network. At the top of the network
   the nodes would have many matches and as we go down the network, there would be 
   fewer matches. At the very bottom of the network are the terminal nodes. In Dr.
   Forgy's 1982 paper, he described 4 basic nodes: root, 1-input, 2-input and
@@ -40,7 +40,7 @@
   cycles. To make things efficient, the engine should only pass the object to
   the nodes that match the object type. The easiest way to do this is to
   create an ObjectTypeNode and have all 1-input and 2-input nodes descend from
-  it. This way, if an application asserts a new account, it won't propogate to
+  it. This way, if an application asserts a new account, it won't propagate to
   the nodes for the Order object. In Drools when an object is asserted it
   retrieves a list of valid ObjectTypesNodes via a lookup in a HashMap from
   the object's Class; if this list doesn't exist it scans all the ObjectTypde
@@ -87,12 +87,12 @@
     </mediaobject>
   </figure>
 
-  <para>Drools extends Rete by optimising the propagation from ObjectTypdeNode
+  <para>Drools extends Rete by optimizing the propagation from ObjectTypdeNode
   to AlphaNode using hashing. Each time an AlphaNode is added to an
   ObjectTypdeNode it adds the literal value as a key to the HashMap with the
   AlphaNode as the value. When a new instance enters the ObjectTypde node,
   rather than propagating to each AlphaNode, it can instead retrieve the
-  correct AlphaNode from the HashMap - avoiding unecessary literal
+  correct AlphaNode from the HashMap - avoiding unnecessary literal
   checks.</para>
 
   <para>There are two two-input nodes; JoinNode and NotNode - both are
@@ -104,8 +104,8 @@
   checks. BetaNodes also have memory. The left input is called the Beta Memory
   and remembers all incoming tuples. The right input is called the Alpha
   Memory and remembers all incoming objects. Drools extends Rete by
-  performaning indexing on the BetaNodes. For instance, if we know that a
-  BetaNode is peforming a check on a String field, as each object enters we
+  performing indexing on the BetaNodes. For instance, if we know that a
+  BetaNode is performing a check on a String field, as each object enters we
   can do a hash lookup on that String value. This means when facts enter from
   the opposite side, instead of iterating over all the facts to find valid
   joins, we do a lookup returning potentially valid candidates. At any

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -13,7 +13,7 @@
     structure for the "descr"; where the "descr" indicates the AST that
     "describes" the rules. The AST is then passed to the Package Builder which
     produces Packages. Package Builder also undertakes any code generation and
-    compilation that is necessary for the creation of the Pacakge. A Packge
+    compilation that is necessary for the creation of the Package. A Package
     object is self contained and deployable, in that it's a serialized object
     consisting of one or more rules.</para>
 
@@ -35,7 +35,7 @@
     Packages. Packages can be added and removed from the RuleBase at any time.
     A RuleBase can instantiate one or more WorkingMemories at any time; a weak
     reference is maintained, unless configured otherwise. The Working Memory
-    consists of a number of sub components, inculding Working Memory Event
+    consists of a number of sub components, including Working Memory Event
     Support, Truth Maintenance System, Agenda and Agenda Event Support. Object
     insertion may result in the creation of one or more Activations. The
     Agenda is responsible for scheduling the execution of these
@@ -78,7 +78,7 @@
     (description) AST models from a provided Reader instance. ProcessBuilder
     reads in an xstream serialisation representation of the Rule Flow.
     PackageBuilder provides convienience APIs so that you can mostly forget
-    about those classes. The three convienience methods are
+    about those classes. The three convenience methods are
     "addPackageFromDrl", "addPackageFromXml" and addRuleFlow - all take an
     instance of Reader as an argument. The example below shows how to build a
     package that includes both XML, DRL and rule files and a ruleflow file,
@@ -100,7 +100,7 @@
     InvalidRulePackage when a broken Package is added, the detailed error
     information is stripped and only a toString() equivalent is available. If
     you interrogate the PackageBuilder itself much more information is
-    aviailable.</para>
+    available.</para>
 
     <example>
       <title>Checking the PackageBuilder for errors</title>
@@ -129,12 +129,12 @@
       </mediaobject>
     </figure>
 
-    <para>It has default values that can be overriden programmatically via
+    <para>It has default values that can be overridden programmatically via
     setters or on first use via property settings. At the heart of the
     settings is the ChainedProperties class which searches a number of
     locations looking for drools.packagebuilder.conf files; as it finds them
     it adds the properties to the master propperties list; this provides a
-    level precedence. In order of precendence those lolcations are: System
+    level precedence. In order of precedence those locations are: System
     Properties, user defined file in System Properties, user home directory,
     working directory, various META-INF locations. Further to this the
     droosl-compiler jar has the default settings in its META-INF
@@ -166,7 +166,7 @@
       </mediaobject>
     </figure>
 
-    <para>The JavaDialectConfiguration allows th compiler and language levels
+    <para>The JavaDialectConfiguration allows the compiler and language levels
     to be supported. You can override by setting the
     "drools.dialect.java.compiler" property in a packagebuilder.conf file that
     the ChainedProperties instance will find, or you can do it at runtime as
@@ -290,7 +290,7 @@
     on the continually re-generation of the Rule Base; which is
     expensive.</para>
 
-    <para>A Rule Base instance is threadsafe, in the sense that you can have
+    <para>A Rule Base instance is thread safe, in the sense that you can have
     the one instance shared across threads in your application, which may be a
     web application, for instance. The most common operation on a rulebase is
     to create a new rule session; either stateful or stateless.</para>
@@ -317,12 +317,12 @@
     method to add an individual rule - to achieve this just add a new package
     with a single rule in it.</para>
 
-    <para>RuleBaseConfigurator can be used to specify additional behaviour of
+    <para>RuleBaseConfigurator can be used to specify additional behavior of
     the RuleBase. RuleBaseConfiguration is set to immutable after it has been
-    added to a Rule Base. Nearly all the engine optimisations can be turned on
-    and off from here, and also the execution behviour can be set. Users will
-    generally be concerned with insertion behaviour (identity or equality) and
-    cross product bheaviour(remove or keep identity equals cross
+    added to a Rule Base. Nearly all the engine optimizations can be turned on
+    and off from here, and also the execution behavior can be set. Users will
+    generally be concerned with insertion behavior (identity or equality) and
+    cross product behavior(remove or keep identity equals cross
     products).</para>
 
     <programlisting>RuleBaseConfiguration conf = new RuleBaseConfiguration();
@@ -498,11 +498,11 @@
       System Shell).</para>
 
       <para>The origins of shadow facts traces back to the concept of truth
-      maintenance. The basic idea is that an expert system should gaurantee
+      maintenance. The basic idea is that an expert system should guarantee
       the derived conclusions are accurate. A running system may alter a fact
       during evaluation. When this occurs, the rule engine must know a
       modification occurred and handle the change appropriately. There's
-      generally two ways to gaurantee truthfullness. The first is to lock all
+      generally two ways to guarantee truthfulness. The first is to lock all
       the facts during the inference process. The second is to make a cache
       copy of an object and force all modifications to go through the rule
       engine. This way, the changes are processed in an orderly fashion.
@@ -692,7 +692,7 @@
     environments such as JEE.</para>
 
     <para>StatelessSessions also support sequential mode, which is a special
-    optimised mode that uses less memory and executes faster; plesae see the
+    optimised mode that uses less memory and executes faster; please see the
     Sequential section for more details.</para>
   </section>
 
@@ -714,7 +714,7 @@
     </figure>
 
     <para>The Agenda is a RETE feature. During a Working Memory Action rules
-    may become fully matched and elegible for execution; a single Working
+    may become fully matched and eligible for execution; a single Working
     Memory Action can result in multiple eligible rules. When a rule is fully
     matched an Activation is created, referencing the Rule and the matched
     facts, and placed onto the Agenda. The Agenda controls the execution order
@@ -758,9 +758,9 @@
     are taking place, no rules are being fired.</para>
 
     <section>
-      <title>Conflict Resultion</title>
+      <title>Conflict Resolution</title>
 
-      <para>Conflict resolution is required when there are mutliple rules on
+      <para>Conflict resolution is required when there are multiple rules on
       the agenda. As firing a rule may have side effects on working memory,
       the rule engine needs to know in what order the rules should fire (for
       instance, firing ruleA may cause ruleB to be removed from the
@@ -830,7 +830,7 @@
       <para>Filters are optional implementations of a the filter interface
       which are used to allow/or deny an activation from firing (what you
       filter on, is entirely up to the implementation). Drools provides the
-      following convienience default implementations</para>
+      following convenience default implementations</para>
 
       <itemizedlist>
         <listitem>
@@ -870,9 +870,9 @@
     conditions that could support the logical assertion, only then will it be
     retracted).</para>
 
-    <para>Normal insertinos are said to be “STATED” (ie The Fact has been
+    <para>Normal insertions are said to be “STATED” (ie The Fact has been
     stated - just like the intuitive concept). Using a HashMap and a counter
-    we track how many times a particuar equality is STATED; this means we
+    we track how many times a particular equality is STATED; this means we
     count how many different instances are equal. When we logically insert an
     object we are said to justify it and it is justified by the firing rule.
     For each logical insertion there can only be one equal object, each
@@ -886,7 +886,7 @@
     override works depends on the configuration setting
     "WM_BEHAVIOR_PRESERVE". When the property is set to discard we use the
     existing handle and replace the existing instance with the new Object -
-    this is the default behaviour - otherwise we overrde it to STATED but we
+    this is the default behavior - otherwise we override it to STATED but we
     create an new FactHandle.</para>
 
     <para>This can be confusing on a first read, so hopefully the flow charts
@@ -967,7 +967,7 @@
       <para>It is important to note that for Truth Maintenance (and logical
       assertions) to work at all, your Fact objects (which may be Javabeans)
       override equals and hashCode methods (from java.lang.Object) correctly.
-      As the truth maintnance system needs to know when 2 different physical
+      As the truth maintenance system needs to know when 2 different physical
       objects are equal in value, BOTH equals and hashCode must be overridden
       correctly, as per the Java standard.</para>
 
@@ -983,7 +983,7 @@
 
     <para>The event package provides means to be notified of rule engine
     events, including rules firing, objects being asserted, etc. This allows
-    you to seperate out logging/auditing activities from the main part of your
+    you to separate out logging/auditing activities from the main part of your
     application (and the rules) - as events are a cross cutting
     concern.</para>
 
@@ -1090,7 +1090,7 @@
     happens if we assume a stateless session, where after the initial data set
     no more data can be asserted or modified (no rule re-evaluations) and
     rules cannot be added or removed? This means we can start to make
-    assumptions to minimise what work the engine has to do.</para>
+    assumptions to minimize what work the engine has to do.</para>
 
     <orderedlist>
       <listitem>

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -45,19 +45,19 @@
     how to build and alter a database schema to hold validation rules. The
     book then shows how to generate VB code from those validation rules to
     validate data entry - while a very valid and useful topic for some, it
-    caused quite a suprise to this author, unaware at the time in the
+    caused quite a surprise to this author, unaware at the time in the
     subtleties of Rules Engines differences, who was hoping to find some
     hidden secrets to help improve the Drools engine. JBoss jBPM uses
     expressions and delegates in its Decision nodes; which control the
     transitions in a Workflow. At each node it evaluates has a rule set that
-    dicates the transition to undertake - this is also a Rule Engine. While a
+    dictates the transition to undertake - this is also a Rule Engine. While a
     Production Rule System is a kind of Rule Engine and also an Expert System,
     the validation and expression evaluation Rule Engines mention previously
     are not Expert Systems.</para>
 
     <para>A Production Rule System is turing complete with a focus on
     knowledge representation to express propositional and first order logic in
-    a concise, non ambigious and declarative manner. The brain of a Production
+    a concise, non ambiguous and declarative manner. The brain of a Production
     Rules System is an Inference Engine that is able to scale to a large
     number of rules and facts. The Inference Engine matches facts and data,
     against Production Rules, also called Productions or just Rules, to infer
@@ -103,7 +103,7 @@
     maintenance. The Drools <indexterm>
         <primary>Rete</primary>
       </indexterm> Rete implementation is called ReteOO, signifying that
-    Drools has an enhanced and optimised implementation of the Rete algorithm
+    Drools has an enhanced and optimized implementation of the Rete algorithm
     for Object Oriented systems. Other Rete based engines also have marketing
     terms for their proprietary enhancements to Rete, like RetePlus and Rete
     III. It is important to understand that names like Rete III are purely
@@ -123,7 +123,7 @@
     of rules and facts may result in many rules being true for the same fact
     assertion, these rules are said to be in conflict. The Agenda manages the
     execution order of these conflicuting rules using a Conflict Resolution
-    stategy.</para>
+    strategy.</para>
 
     <figure>
       <title>A Basic Rete network</title>
@@ -142,10 +142,10 @@
     <para>A Production Rule System's Inference Engine is stateful and able to
     enforce truthfulness - called Truth Maintence. A logical relationship can
     be declared by actions which means the action's state depends on the
-    inference remaining true; when it is no longer true the logical dependant
+    inference remaining true; when it is no longer true the logical dependent
     action is undone. The "Honest Politician" is an example of Truth
     Maintenance, which always ensures that hope can only exist for a
-    decomcracy while we have honest politicians.</para>
+    democracy while we have honest politicians.</para>
 
     <programlisting>
 when

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -22,7 +22,7 @@
     </listitem>
   </orderedlist>
 
-  <para>We will attempt to adderess these questions below.</para>
+  <para>We will attempt to address these questions below.</para>
 
   <section>
     <title>Advantages of a Rule Engine</title>
@@ -63,7 +63,7 @@
       <listitem>
         <para>Speed and Scalability</para>
 
-        <para>The Rete algorithm, Leaps algorithm, and its descendents such as
+        <para>The Rete algorithm, Leaps algorithm, and its descendants such as
         Drools' Reteoo (and Leaps), provide very efficient ways of matching
         rule patterns to your domain object data. These are especially
         efficient when you have datasets that do not change entirely (as the
@@ -119,7 +119,7 @@
     answer, some more explanation is required. The reason why there is no
     "traditional" approach is possibly one of the following: <itemizedlist>
         <listitem>
-          <para>The problem is just too fiddly for traditional code.</para>
+          <para>The problem is just too fiddle for traditional code.</para>
 
           <para>The problem may not be complex, but you can't see a
           non-fragile way of building it.</para>
@@ -239,10 +239,10 @@
 
     <para>Many people have also implemented data-driven systems successfully
     in the past (where there are control tables that store meta-data that
-    changes your applications behaviour) - these can work well when the
+    changes your applications behavior) - these can work well when the
     control can remain very limited. However, they can quickly grow out of
     control if extended to much (such that only the original creators can
-    change the applications behaviour) or they cause the application to
+    change the applications behavior) or they cause the application to
     stagnate as they are too inflexible.</para>
   </section>
 

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-DSL.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -6,17 +6,17 @@
       <primary>Domain Specific Languages</primary>
     </indexterm>(or DSLs) are a way of extending the rule language to your
   problem domain. They are wired in to the rule language for you, and can make
-  use of all the underlying rule langauge and engine features.</para>
+  use of all the underlying rule language and engine features.</para>
 
   <section>
     <title>When to use a DSL</title>
 
-    <para>DSLs can serve as a layer of seperation between rule authoring (and
+    <para>DSLs can serve as a layer of separation between rule authoring (and
     rule authors) and the domain objects that the engine operates on. DSLs can
     also act as "templates" of conditions or actions that are used over and
     over in your rules, perhaps only with parameters changing each time. If
     your rules need to be read and validated by less technical folk, (such as
-    Business Analysts) the DSLs are definately for you. If the conditions or
+    Business Analysts) the DSLs are definitely for you. If the conditions or
     consequences of your rules follow similar patterns which you can express
     in a template. You wish to hide away your implementation details, and
     focus on the business rule. You want to provide a controlled means of
@@ -48,7 +48,7 @@
       <programlisting>[when]This is {something}=Something(something=={something})</programlisting>
     </example>
 
-    <para>Refering to the above example, the [when] refers to the scope of the
+    <para>Referring to the above example, the [when] refers to the scope of the
     expression: ie does it belong on the LHS or the RHS of a rule. The part
     after the [scope] is the expression that you use in the rule (typically a
     natural language expression, but it doesn't have to be). The part on the
@@ -71,7 +71,7 @@
     DSL expressions to generate a target expression. The best way around this
     is to make sure that the {tokens} are enclosed with characters or words.
     This means that the parser will scan along the sentence, and pluck out the
-    value BETWEEN the characters (in the example below they are doublequotes).
+    value BETWEEN the characters (in the example below they are double-quotes).
     Note that the characters that surround the token are not included in when
     interpolating, just the contents between them (rather then all the way to
     the end of the line, as would otherwise be the case).</para>
@@ -134,14 +134,14 @@
     unit test as you go (like a good agile citizen!). Once you feel
     comfortable, you can look at extracting a domain language to express what
     you are doing in the rules. Note that once you have started using the
-    "expander" keyword, you will get errors if the parser does not recognise
+    "expander" keyword, you will get errors if the parser does not recognize
     expressions you have in there - you need to move everything to the DSL. As
     a way around this, you can prefix each line with "&gt;" and it will tell
     the parser to take that line literally, and not try and expand it (this is
     handy also if you are debugging why something isn't working).</para>
 
     <para>As you work through building up your DSL, you will find that the DSL
-    configuration stabilises pretty quickly, and that as you add new rules and
+    configuration stabilizes pretty quickly, and that as you add new rules and
     edit rules you are reusing the same DSL expressions over and over. The aim
     is to make things as fluent as possible.</para>
 
@@ -180,8 +180,8 @@
     <para>A common requirement when writing rule conditions is to be able to
     add many constraints to fact declarations. A fact may have many (dozens)
     of fields, all of which could be used or not used at various times. To
-    come up with every combination as seperate DSL statements would in many
-    cases not be feasable.</para>
+    come up with every combination as separate DSL statements would in many
+    cases not be feasible.</para>
 
     <para>The DSL facility allows you to achieve this however, with a simple
     convention. If your DSL expression starts with a "-", then it will be
@@ -259,12 +259,12 @@
     fashioned way.</para>
 
     <para>Rules engines require a object or data model to operate on - in many
-    cases you may know this up front. In othercases the model will be
+    cases you may know this up front. In other cases the model will be
     discovered with the rules. In any case, rules generally work better with
     simpler flatter object models. In some cases, this may mean having a rule
     object model which is a subset of the main applications model (perhaps
     mapped from it). Object models can often have complex relationships and
-    hierachies in them - for rules you will want to simplify and flatten the
+    hierarchies in them - for rules you will want to simplify and flatten the
     model where possible, and let the rule engine infer relationships (as it
     provides future flexibility). As stated previously, DSLs can have an
     advantage of providing some insulation between the object model and the
@@ -273,7 +273,7 @@
     <para>Coming up with a DSL is a collaborative approach for both technical
     and domain experts. Historically there was a role called "knowledge
     engineer" which is someone skilled in both the rule technology, and in
-    capturing rules. Overa short period of time, your DSL should stabilise,
+    capturing rules. Over a short period of time, your DSL should stabilize,
     which means that changes to rules are done entirely using the DSL. A
     suggested approach if you are starting from scratch is the following
     workflow: <itemizedlist>
@@ -298,7 +298,7 @@
         <listitem>
           <para>Use the above DSL, and try to write the rules just like that
           appear in the "if then" statements from the first and second steps.
-          Iterate this process until patterns appear and things stabilise. At
+          Iterate this process until patterns appear and things stabilize. At
           this stage, you are not so worried about the rule language
           underneath, just the DSL.</para>
         </listitem>
@@ -317,7 +317,7 @@
         </listitem>
       </itemizedlist></para>
 
-    <para>A challanging concept to express in DSLs is bound variables. A tip
+    <para>A challenging concept to express in DSLs is bound variables. A tip
     for this is to have a DSL expressions that just bind a given variable name
     to an Object Type (with no conditions - you can add conditions to that
     bound object type in subsequent statements). You can then use that name

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Overview.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Overview.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Overview.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -9,7 +9,7 @@
   <para>Drools 4.0 has a "native" rule language that is non XML textual
   format. This format is very light in terms of punctuation, and supports
   natural and domain specific languages via "expanders" that allow the
-  language to morph to your problem domain. This chapter is mostly concered
+  language to morph to your problem domain. This chapter is mostly concerted
   with the native rule format. The Diagrams used are known as "rail road"
   diagrams, and are basically flow charts for the language terms. For the
   technically very keen, you can also refer to "DRL.g" which is the Antlr3
@@ -30,7 +30,7 @@
     help with managing large numbers of rules. A DRL file is simply a text
     file.</para>
 
-    <para>The overal structure of a rule file is:</para>
+    <para>The overall structure of a rule file is:</para>
 
     <example>
       <title>Rules file</title>
@@ -58,7 +58,7 @@
   <section>
     <title>What makes a rule</title>
 
-    <para>For the impatients, just as an early view, a rule has the following
+    <para>For the inpatients, just as an early view, a rule has the following
     rough structure:<programlisting><emphasis role="bold">rule</emphasis> <replaceable>"name"</replaceable>
     <replaceable>attributes</replaceable>
     <emphasis role="bold">when</emphasis>
@@ -73,8 +73,8 @@
     syntax which is covered below. RHS is basically a block that allows
     dialect specific semantic code to be executed.</para>
 
-    <para>It is important to note that whitepace is not important, EXCEPT in
-    thse case of domain specific languages, in which case each line is
+    <para>It is important to note that white space is not important, EXCEPT in
+    these case of domain specific languages, in which case each line is
     processed before the following line (and spaces may be significant to the
     domain language).</para>
   </section>

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Package.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Package.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Package.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -84,7 +84,7 @@
     </figure>
 
     <para>The expander statement (optional) is used to specify domain specific
-    language (DSL) configurations (which are normally stored in a seperate
+    language (DSL) configurations (which are normally stored in a separate
     file). This provides clues to the parser as how to understand what you are
     raving on about in your rules. It is important to note that in Drools 4.0
     (that is different from Drools 3.x) the expander declaration is mandatory
@@ -119,7 +119,7 @@
     never be reasoned over, and only use them in rules LHS if the global has a
     constant immutable value. The engine is not notified and does not track
     globals value changes. Incorrect use of globals in constraints may yield
-    suprising results - surprising in a bad way, like when a doctor says
+    surprising results - surprising in a bad way, like when a doctor says
     "thats interesting" to a chest XRay of yours.</para>
 
     <para>If multiple packages declare globals with the same identifier they
@@ -176,7 +176,7 @@
     the data to the working memory.</para>
 
     <para>It is strongly discouraged to set (or change) a global value from
-    inside your rules. We recomend to you always set the value from your
+    inside your rules. We recommend to you always set the value from your
     application using the working memory interface.</para>
   </section>
 </section>
\ No newline at end of file

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -19,7 +19,7 @@
   <para>A rule specifies that "when" a particular set of conditions occur,
   specified in the Left Hand Side (LHS), then do this, which is specified as a
   list of actions in the Right Hand Side (RHS). A common question from users
-  is "why use when instead of if". "when" was chosen over "if" becuase "if" is
+  is "why use when instead of if". "when" was chosen over "if" because "if" is
   normally part of a procedural execution flow, where at a specific point in
   time it checks the condition. Where as "when" indicates it's not tied to a
   specific evaluation sequence or point in time, at any time during the life
@@ -70,9 +70,9 @@
   </example>
 
   <section>
-    <title>Rule Attriutes</title>
+    <title>Rule Attributes</title>
 
-    <para>Rule attributes provide a declarative way to influence the behaviour
+    <para>Rule attributes provide a declarative way to influence the behavior
     of the rule, some are quite simple, while others are part of complex sub
     systems; such as ruleflow. To get the most from Drools you should make
     sure you have a proper understanding of each attribute.</para>
@@ -152,7 +152,7 @@
       <para>Rules that belong to the same named activation-group will only
       fire exclusively. In other words, the first rule in an activation-group
       to fire will cancel the other rules activations (stop them from firing).
-      The Activtion group attribute is any string, as long as the string is
+      The Activation group attribute is any string, as long as the string is
       identical for all the rules you need to be in the one group.</para>
 
       <para>NOTE: this used to be called Xor group, but technically its not
@@ -173,7 +173,7 @@
       expressions in the LHS or the RHS code block. Currently two dialects are
       available, Java and MVEL. While the dialect can be specified at the
       package level, this attribute allows the package definition to be
-      overriden.</para>
+      overridden.</para>
     </section>
 
     <section>
@@ -183,7 +183,7 @@
 
       <para>type : String, which contains a Date/Time definition</para>
 
-      <para>A rule can only activate if the current date and time is afer
+      <para>A rule can only activate if the current date and time is after
       date-effective attribute.</para>
     </section>
 
@@ -194,7 +194,7 @@
 
       <para>type : String, which contains a Date/Time definition</para>
 
-      <para>A rule cannot activate if the current date and time is afer
+      <para>A rule cannot activate if the current date and time is after
       date-expires attribute.</para>
     </section>
 
@@ -338,8 +338,8 @@
 
       <para>Inside of the Pattern parenthesis is where all the action happens.
       A constraint can be either a Field Constraint, Inline Eval (called a
-      predicate in 3.0) or a Constraint Group. Constraints can be seperated by
-      the following symboles ',', '&amp;&amp;' or '||'.</para>
+      predicate in 3.0) or a Constraint Group. Constraints can be separated by
+      the following symbols ',', '&amp;&amp;' or '||'.</para>
 
       <figure>
         <title>Constraints</title>
@@ -517,17 +517,17 @@
           "type") - we use the standard jdk Introspector class to do this
           mapping.</para>
 
-          <para>For example, refering to our Cheese class, the following :
+          <para>For example, referring to our Cheese class, the following :
           Cheese(type == ...) uses the getType() method on the a cheese
           instance. If a field name cannot be found it will resort to calling
           the name as a no argument method; "toString()" on the Object for
           instance can be used with Cheese(toString == ..) - you use the full
-          name of the method with correct capitalisation, but not brackets. Do
+          name of the method with correct capitalization, but not brackets. Do
           please make sure that you are accessing methods that take no
           parameters, and are in-fact "accessors" (as in, they don't change
           the state of the object in a way that may effect the rules -
           remember that the rule engine effectively caches the results of its
-          matching inbetween invocations to make it faster).</para>
+          matching in between invocations to make it faster).</para>
         </section>
 
         <section>
@@ -602,12 +602,12 @@
           <para>You can do checks against fields that are or maybe null, using
           == and != as you would expect, and the literal "null" keyword, like:
           Cheese(type != null). If a field is null the evaluator will not
-          throw an expception and will only return true if the value is a null
+          throw an exception and will only return true if the value is a null
           check. Coercion is always attempted if the field and the value are
           of different types; exceptions will be thrown if bad coercions are
           attempted. i.e. if "ten" is provided as a string in a number
           evaluator, where as "10" would coerce to a numeric 10. Coercion is
-          always in favour of the field type and not the value type.</para>
+          always in favor of the field type and not the value type.</para>
         </section>
 
         <section>
@@ -654,8 +654,8 @@
             only applicable to string fields, "contains" and "not contains" is
             only applicable to Collection type fields. These operators can be
             used with any value and coercion to the correct value for the
-            evaluator and filed will be attempted, as mention in hte "Values"
-            secion.</para>
+            evaluator and filed will be attempted, as mention in the "Values"
+            section.</para>
 
             <simplesect>
               <title>Matches Operator</title>
@@ -714,7 +714,7 @@
             </simplesect>
 
             <simplesect>
-              <title>not containts</title>
+              <title>not contains</title>
 
               <para><literal>'not contains'</literal> is used to check if a
               field's <indexterm>
@@ -810,7 +810,7 @@
               <title>Date</title>
 
               <para>The date format "dd-mmm-yyyy" is supported by default. You
-              can customise this by providing an alternative date format mask
+              can customize this by providing an alternative date format mask
               as a System property ("drools.dateformat" is the name of the
               property). If more control is required, use the inline-eval
               constraint.</para>
@@ -838,7 +838,7 @@
               <title>Boolean</title>
 
               <para>only true or false can be used. 0 and 1 are not
-              recognised, nor is <literal>Cheese ( smelly )</literal> is
+              recognized, nor is <literal>Cheese ( smelly )</literal> is
               allowed</para>
 
               <example>
@@ -887,7 +887,7 @@
             <indexterm>
                 <primary>declaration</primary>
               </indexterm>Declaration. Valid operators are determined by the
-            type of the field being constrained; coersion will be attempted
+            type of the field being constrained; coercion will be attempted
             where possible. Bound Variable Restrictions using '==' operator,
             provide for very fast execution as we can index using hashing to
             improve performance.</para>
@@ -903,7 +903,7 @@
               is used to constrain the type of Cheese in the following
               Pattern. Any valid java variable name can be used, including
               '$'; which you will often see used to help differentiate
-              declarations from fields. The exampe below shows a declaration
+              declarations from fields. The example below shows a declaration
               bound to the Patterns Object Type instance itself and used with
               a 'contains' operator, note the optional use of '$' this
               time.</para>
@@ -938,7 +938,7 @@
 
             <para>A <indexterm>
                 <primary>Return Value</primary>
-              </indexterm>Return Value restrriction can use any valid Java
+              </indexterm>Return Value restriction can use any valid Java
             primitive or object. Avoid using any Drools keywords as
             Declaration identifiers. Functions used in a Return Value
             Restriction must return time constant results. Previously bound
@@ -960,9 +960,9 @@
           <para>The compound value restriction is used where there is more
           than one possible value, currently only the 'in' and 'not in'
           evaluators support this. The operator takes a parenthesis enclosed
-          comma seperated list of values, which can be a variable, literal,
-          return value or qualified identifier.The 'in' and 'not in'
-          evaluators are actually sugar and are rewriten as a multi
+          comma separated list of values, which can be a variable, literal,
+          return value or qualified identifier. The 'in' and 'not in'
+          evaluators are actually sugar and are rewritten as a multi
           restriction list of != and == restrictions.</para>
 
           <figure>
@@ -1076,7 +1076,7 @@
         is not a current variable the builder looks to see if the identifier
         is a field on the current object type, if it is, the field is auto
         created as a variable of the same name; this is autovivification of
-        field varables inside of inline evals.</para>
+        field variables inside of inline evals.</para>
 
         <para>This example will find all pairs of male/femal people where the
         male is 2 years older than the female; the boyAge variable is auto
@@ -1105,7 +1105,7 @@
         first and re-assert afterwards. If you only have a single parent at
         the root of the graph, when in the MVEL dialect, you can use the
         'modify' keyword and its block setters to write the nested accessor
-        assingments while retracting and inserting the the root parent object
+        assignments while retracting and inserting the the root parent object
         as required. Nested accessors can be used either side of the operator
         symbol.</para>
 
@@ -1131,7 +1131,7 @@
 
       <para>The 'and' Conditional Element is used to group together other
       Conditional Elements. The root element of the LHS is an implicit
-      prefixAnd and doesn't need to be specified. Drools supports both prefix
+      prefix And and doesn't need to be specified. Drools supports both prefix
       and infix; although prefix is the preferred option as grouping is
       implicit which avoids confusion.</para>
 
@@ -1204,14 +1204,14 @@
       <para>The 'or' Conditional Element is used to group together other
       Conditional Elements. Drools supports both prefix and infix; although
       prefix is the preferred option as grouping is implicit which avoids
-      confusion. The behaviour of the 'or' Conditional Element is different
+      confusion. The behavior of the 'or' Conditional Element is different
       than the '||' connective for constraints and restrictions in field
       constraints. The engine actually has no understanding of 'or'
       Conditional Elements, instead via a number of different logic
       transformations the rule is re-written as a number of subrules; the rule
       now has a single 'or' as the root node and a subrule per logical
       outcome. Each subrule can activate and fire like any normal rule, there
-      is no special behaviour or interactions between the subrules - this can
+      is no special behavior or interactions between the subrules - this can
       be most confusing to new rule authors.</para>
 
       <figure>
@@ -1314,7 +1314,7 @@
       <para>Eval is essentially a catch all which allows any semantic code
       (that returns a primitive boolean) to be executed. This can refer to
       variables that were bound in the LHS of the rule, and functions in the
-      rule package. Over use of eval reduces the declarativess of your rules
+      rule package. Over use of eval reduces the declaratives of your rules
       and can result in a poor performing engine. While 'evals' can be used
       anywhere in the Pattern the best practice is to add it as the last
       conditional element in the LHS of a rule.</para>
@@ -1447,7 +1447,7 @@
 </programlisting>
 
       <para>In the above rule, we "select" all Bus object whose type is
-      "english". Then, for each fact that matchs this pattern we evaluate the
+      "english". Then, for each fact that matches this pattern we evaluate the
       following patterns and if they match, the forall CE will evaluate to
       true. </para>
 
@@ -2000,7 +2000,7 @@
 
     <para>The Right Hand Side (RHS) is a common name for the consequence or
     action part of the rule; this part should contain a list of actions to be
-    executed.It is bad practice to use imperative or conditoinal code in the
+    executed. It is bad practice to use imperative or conditional code in the
     RHS of a rule; as a rule should be atomic in nature - "when this, then do
     this", not "when this, maybe do this". The RHS part of a rule should also
     be kept small, thus keeping it declarative and readable. If you find you
@@ -2037,7 +2037,7 @@
     <title>A note on auto boxing/unboxing and primitive types</title>
 
     <para>Drools attempts to preserve numbers in their primitive or object
-    wrappter form, so a variable bound to an int primtive when used in a code
+    wrapper form, so a variable bound to an int primitive when used in a code
     block or expression will no longer need manual unboxing; unlike Drools 3.0
     where all primitives was autoboxed, requiring manual unboxing. A variable
     bound to an object wrapper will remain as an object; the existing jdk1.5

Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-RuleFlow.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-RuleFlow.xml	2007-08-16 07:39:52 UTC (rev 14297)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-RuleFlow.xml	2007-08-16 08:12:38 UTC (rev 14298)
@@ -65,7 +65,7 @@
     done before "Process Order". This means that in your rules, firstly only
     rules which are market as having a ruleflow-group of "Check Order" will be
     considered first, and then "Process Order". Thats about it. You could
-    achieve similar to this with either salience (setting prorities, but this
+    achieve similar to this with either salience (setting priorities, but this
     is harder to maintain, and makes the time-relationship implicit in the
     rules), or agenda groups. However, using a ruleflow makes the order of
     processing explicit, almost like a meta-rule.</para>
@@ -129,16 +129,16 @@
 
     <para>Next step is to join the groups together (if its a simple sequence
     of steps) - you use this by using "create connection" from the component
-    pallette. You should also create an "End" node (also from the component
-    pallette) - you only have one of these.</para>
+    palette. You should also create an "End" node (also from the component
+    palette) - you only have one of these.</para>
 
     <para>In practice, if you are using ruleflow, you will most likely be
     doing more then setting a simple sequence of groups to progress though.
-    You are more likely modelling branches of processing. In this case you use
+    You are more likely modeling branches of processing. In this case you use
     "Split" and "Join" items from the component pallette. You use connections
     to connect from the start to ruleflow groups, or to Splits, and from
     splits to groups, joins etc (ie basically like a simple flow chart that
-    modells your processing). You can work entirelly graphically until you get
+    models your processing). You can work entirely graphically until you get
     the graph approximately right.</para>
 
     <figure>
@@ -157,7 +157,7 @@
     data validation rules are processed (these check for data integrity and
     consistency, that all the information is there). Next there is a decision
     "split" - based on a condition which the rule flow checks (the value of
-    the claim), it will either move on to an "autosettlement" group, or to
+    the claim), it will either move on to an "auto-settlement" group, or to
     another "split", which checks if there was a fatality in the claim. If
     there was a fatality then it determines if the "regular" of fatality
     specific rules will take effect. And so on. What you can see from this is
@@ -177,10 +177,10 @@
       </mediaobject>
     </figure>
 
-    <para>Split types (refering to the above): When you click on a split, you
+    <para>Split types (referring to the above): When you click on a split, you
     will see the above properties panel. You then have to choose the type:
     AND, OR, and XOR. The interesting ones are OR and XOR: if you choose OR,
-    then any of the "ouputs" of the split can happen (ie processing can
+    then any of the "outputs" of the split can happen (ie processing can
     proceed in parallel down more then one path). If you chose XOR, then it
     will be only one path.</para>
 




More information about the jboss-svn-commits mailing list