>
>That's similar to what I had in mind, but remember we would have to account for record level as well as field level rules. I was thinking something more like:
>
>

><rules>
>  <recordrule enforceexpression="balance >= withdrawal" ruletext="Balance before withdrawal must be greater than withdrawal amount."/>
>  <fieldrule field="phone" mask="(999)999-9999" ruletext="The phone number contains illegal characters."/>
>  <fieldrule field="phone" required="true" ruletext="You must enter a telephone number."/>
>
>  .
>  .
>  .
></Rules>
>
>

Hmm...Yeah, that makes some sense. I guess I was lumping record-level login into the the "other" classification. But there really isn't any good reason to not just include that as another type of rule and it really improves the usefulness. I broke out the ruletext thinking that you could use the default message if you wanted to or set it up on a application-level, or class level to override it. That way you're not bloating your XML with 100's of messages that are nearly identical except for a field name & description. Eg.

You must fill in the phone number.
You must fill in the first name.

etc.

I also included the "name" attribute on the rules tag so that you could define a set of rules that were specific to a business object. In your business object you'd have a property that pointed to the business rules that were to be applied.

What I kind of like about all of this, in addition to it's portability, is that you could easily fire off all, or some of the rules via a method or two in your business rules class. Field rules all have a field attribute, record rules have their own tags and all of the rules are grouped together within the rules tags.