[
Lists Home |
Date Index |
Thread Index
]
> From the tutorial, XRules appear to be rather more ad hoc, both in the
> way they are expressed and in what they can do. It may be that
> everything that XRules does could be expressed as one or more rules of
> the form:
>
> If
> xpath-expression
> Then (one or more of the following)
> set xpath-node-expression to xpath-value-expression
> set xpath-variable to xpath-value-expression
> report xpath-value-expression
Essentially yes. But again, the If...Then construct can express almost every
possible rule in every context if you have an expression language flexible
enough to express all possible conditions and actions. But that syntax is
not necessarily the best for all situations, I think. Imagine, for example,
if XSLT was written in this form:
If
xpath-match-expression
Then (one or more of the following)
set xpath-variable to xpath-value-expression
write xpath-value-expression
But you bring up a very interesting point. If all rules languages can,
essentially, be expressed in If...Then constructs, then the choice is based
on syntax. The language with the most human-friendly syntax for a certain
application domain wins. It's not hard to accumulate features into a
language; but it's hard to do that while keeping the language simple. I
think we'll end up with several rules languages; and for each type of
application, one will be the best fit.
> A simpler formulation might invite simple questions that I don't know
> how to answer from the examples. Like, if one context sets a parameter
> to one value and another context sets the parameter to a different
> value, if both contexts succeed, what value does the parameter have? If
> the answer is pick one, then it is very different than semantic
> processing, which can have the ability to pursue both values as
> independent sets of facts ("x" is "a" or "x" is "b") and even to
> calculate the likelihood that one or the other is true.
This one kept me up many nights, and I'm still struggling with it. Here are
my thoughts for handling this in XRules:
1. For XML nodes (which are updated by the <calculate> rule), the answer is
simple: since XML doesn't allow a node to have more than one value at the
same time, then we have to either pick a value or limit the number
<calculate> rules to one per node. I chose the second because the first adds
complexity that increases the chances of errors, especially if you have a
lot of rules to manage. So, in the current Dynamic DOM implementation
(v0.4.2), an error is raised immediately if more than one <calculate> rules
target the same node.
2. For XRules properties (created by the <property> rule), the answer is not
so simple. I have identified many scenarios where there is a need to allow a
property to hold several different values at the same time. And, therefore,
I'm hoping to add this feature to XRules sooner than later. But the
challenge is how to add the feature without introducing too much extra
complexity to the language. Until I find the answer, the current
implementation only allows one value at a time for each property.
> Suppose one rule establishes a value that causes another rule to succeed
> and it resets the value so that the first rule is invoked? Does the
> system cycle infinitely or does it reach a fixed point?
>
> Is there an efficient algorithm for determining which rules must be
> (re)tested?
If not detected, this type of circular dependency could cause the system to
fall into an infinite loop. Therefore, the implementation will have to
prevent it. The current Dynamic DOM version, doesn't detect that, but
hopefully it'll be in the next one.
Best regards,
Waleed
http://www.xrules.org
|
