Lists Home |
Date Index |
I would concur with Roland Merrick on this issue. The XForms model has great
potential as a way of defining distributable business rule sets (whether or
not you need a form). The nice thing is that it the declarative rules are
designed to layer over an existing XML schema language (W3C XML Schema). So
the XForms model could be seen as XSD extensions, though of course it is
I work for a vertical industry standards body that develops schemas for data
interchange in the UK life insurance industry. We already develop schemas,
and we are just about to begin shipping XForms models along side the
schemas, so that we can express a high proportion (all in most
circumstances) of the business rules that are currently left as prose text
in our documentation. This means that the community gets unambiguous,
Furthermore, because we are developing industry wide standards, business
rules are expressed against company neutral data structures.
At the very least we are giving implementers better documentation (the prose
documentation generated from XML Schema + XForms model) and debugging tools
(attach an appropriate UI to your model and you get a useful validity report
for an XML instance).
I notice that you have already had a reply from Rick Jelliffe, mentioning
that Schematron is also a good fit for your requirements. You might want to
look at the ISO DSDL activity that is working to allow combinations of Relax
NG and Schematron schemas. In many ways the combination of XSD + XForms
Model mirrors Relax NG + Schematron. My hope is that we might see some
convergence in the future, rather than the emergence of yet more
alternatives for defining business rulesets.
So, if you think you can build on work that has already been done, or is in
progress, or even feed requirements directly into those efforts, please do.
All the best
> From: Waleed Abdulla <Waleed_Abdulla@xrules.org>
> Date: Thu, 10 Mar 2005 02:16:35 -0800
> To: <firstname.lastname@example.org>
> Subject: [xml-dev] XRules: Mind your own business rules
> Hi everyone,
> Thanks to XML and Web services, we're on the verge of an explosive
> growth in the amounts of data that our software applications exchange with
> each other. Some might argue that we're already drowning in it, but I think
> we've only seen the tip of the iceberg.
> With that it becomes more important to be able to exchange business
> rules between applications. So if I'm a service provider, I want to let my
> user's software agent know what my business rules are so it can provide a
> better experience to the user. For example, I want my user's software agent
> to know that I charge $7 for ground shipping and $20 for overnight if the
> order is under $50, and that ground shipping is free if the order is over
> $50. And, I want the user's software to be able to dynamically calculate the
> shipping cost locally as the user is editing the order. Basically, I want to
> be able to give my business rules to someone else's software and have it
> understand them (or, at least, behave as if it understands them).
> I've done a lot of work in this area and I'm looking to find out if
> anyone is interested in participating in the ongoing design and development
> of this effort. It involves two components:
> 1. XRules, which is an XML rules language that expresses constraints,
> calculations, interdependencies, and properties that exist among nodes of an
> XML document.
> 2. The Dynamic DOM, which is an extension of the DOM that dynamically
> executes and validates XRules rules. For example, you change the ItemPrice
> node and the ItemTotal node recalculates automatically.
> This is a fragment of a simple XRules document that shows how the total
> price per item is calculated in a purchase order, and highlights (through
> metadata properties) the items that exceed the allowed limit (a tutorial is
> available at www.xrules.org):
> <xr:ruleset context="/PurchaseOrder/Item">
> <xr:calculate target="ItemTotal" value="UnitPrice * Quantity" />
> <xr:bind target=".">
> <xr:property name="OverLimit" dvalue="boolean(. > ../MaxPerItem)" />
> And, this is a sample purchase order:
> You can also download examples and tools from http://www.xrules.org.
> So, if you're interested in the idea, or have suggestions or comments,
> I'd like to hear it. And, if you think this is the worst thing since
> chocolate bacon, then, well, I'd like to hear it too.
> And, what's the best way to propose something like this to W3C for their
> consideration? Or does it have to be submitted by a W3C member?
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.
Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents. It is your responsibility to scan for viruses. Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control. When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited. If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender. The contents of this e-mail are protected by copyright. All rights reserved.
Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 4th floor, Saltire Court, 20 Castle Terrace, Edinburgh EH1 2EN.