Mike,
One thing to keep in mind when using the <calculate> rule is that
the DynamicDOM will try to bring the values of the XML nodes to a stable
state by executing all the relevant rules and, in some cases, executing
the same rule multiple times. This will happen if the value of the node
is calculated using the value of the node itself (self reference).

For example, the following rule calculates the value of fruit using
the value of the node itself.

<xr:calculate target="fruit">
<xr:value when="fruit = 'A'">'Apple'</xr:value>
<xr:value when="fruit = 'B'">'Banana'</xr:value>
</xr:calculate>

So, the order of execution is going to be like:
1. Initial state: fruit = A
2. Execute rule
3. Value of fruit is now = Apple
4. The changing of the value of the fruit node triggers the execution of
the same rule again. That's because when a node changes, the DynamicDOM
will automatically recalculate the values of all affected nodes.
5. Execute rule again
6. Since fruit = Apple, which is not in the list of 'when' conditions,
then the default <value> element will be used (one that doesn't have the
'when' attribute).
7. And, since there is no default <value>, then the value of fruit is
set to empty.

This should explain why the value of the node is set to empty even
when one of the 'when' conditions apply.

However, to your point, I do agree that the default behavior should
leave the node value unchanged. It seems more intuitive and in line with
what a user would expect. I'm planning to change the behavior described
in point 7 above in the next release to be:

7. And, since there is no default <value>, then the value of fruit is
not updated.



As for your question about accessing the <config> data programmatically,
it's not in the current implementation. The "XRules Object Model" is
still very limited, and as of now, only allows access to the rules. The
only hack I can think of is to load the XRules document in a standard
DOM and treat it as any other XML document, then you can locate the
<config> areas using XPath.

And, thanks a lot for your offer to help in beta testing. That, and any
feedback or comments, are the most valuable things I could receive.

Thanks,
Waleed




-----Original Message-----
From: notify@yahoogroups.com [mailto:notify@yahoogroups.com] On Behalf
Of mike61079
Sent: Monday, May 29, 2006 9:00 PM
To: Waleed K. Abdulla
Subject: Re: a thank you and a question about string matching

Thanks for the answers to my questions! It still seems weird there isn
't even a W3C standard for this type of thing. But from what I can
see you're working on making that happen. Oh and thank you for making
great docs for this, between them and the utility this was really
easy to get going.

One thing weird about <calculate> which I haven't had time to
investigate is if I were to just do this:

<xr:calculate target="fruit">
<xr:value when="fruit = 'A'">'Apple'</xr:value>
<xr:value when="fruit = 'B'">'Banana'</xr:value>
</xr:calculate>

Without the <xr:value>fruit</xr:value> part it will just leave that
node empty even if it matches one of the WHEN's. I would have thought
it would have just left the node as is.

Oh one more thing, is there a way to programmatically in C# access
the config() data? I couldn't find anything in docs for this and my
brief look at the code didn't come up with anything obvious.

Thanks again for info! I am really looking forward to new builds and
would be happy to help you out beta test if you needed it.

--- In xrules@yahoogroups.com, "Waleed K. Abdulla" <waleed_abdulla@...
> wrote:
>
> Mike,
> Thanks for your nice words. The business rules space is quite
large
> and there are different tools and languages depending on what you
need.
> You could probably find a lot of tools if you search using the terms
> "rules engine". However, to my limited knowledge, I'm not aware of a
> rules language focused solely on XML the same way as XRules.
>
> Your use of the <calculate> rule to replace strings is correct
and
> it should work just fine. In a future release of XRules there will
also
> be support for embedding JavaScript functions in the XRules
document,
> and that will provide another option. Another possibility (but I
haven't
> tried it) is creating an extended XPath function in your
application to
> replace the strings and adding it to the XRules Context object. This
> should make the DynamicDOM call out to your custom function as
needed.
> You'll still use the <calculate> rule, but you'll be calling a
custom
> XPath function to do the string replacement. This, however, seems
like
> an overkill for what you need. Your method is a lot simpler.
>
> Regards,
> Waleed
>
>
>
>
>
> -----Original Message-----
> From: xrules@yahoogroups.com [mailto:xrules@yahoogroups.com] On
Behalf
> Of mike61079
> Sent: Sunday, May 28, 2006 7:47 PM
> To: xrules@yahoogroups.com
> Subject: [xrules] a thank you and a question about string matching
>
> Hello. I just wanted to say that this is a really great XML rules
> library. I had already kind of made my own and then decided as
> requests were getting more complicated to do research on what else
> was out there. I came across this and it's perfect. It also seems
to
> work in .NET 2.0 very well which is great! I am surprised this is
not
> talked about more, it was kind of hard to find. Is there any
> comparable W3C spec for doing this? What about comparable
> applications? Who else makes something like this? It seems rather
> unique as its focus is purely on XML. Which is perfect!
>
> Also I had a usage question. I need to replace certain strings in a
> node that match a list or otherwise leave them as they are. So I
used
> calculate to do that like this:
>
> <xr:calculate target="value">
> <xr:value when="value = 'A'">'Apple'</xr:value>
> <xr:value when="value = 'B'">'Banana'</xr:value>
> <xr:value>value</xr:value>
> </xr:calculate>
>
> Is this correct? Is there a better way?
>