[
Lists Home |
Date Index |
Thread Index
]
I appreciate the openness to discuss the possibility of breaking out the
XForms model into its own specs. And, if that happens, I would be very
interested in that effort, as I'm sure many others.
However, taking the XForms model as it stands today, performing some
cosmetic changes, and then promoting it as a rules language is, I'm afraid,
not the right approach. The scope change from working with forms into
working with a wide universe of applications ranging from Web services to
rules engines is too great that it requires nothing less than a major
redesign effort.
The right approach, in my humble opinion, is to start fresh and gather
all the specs that relate to the field and pick the best features from each
one. And, I would suggest (warning: shameless promotion ahead) that XRules
is a good starting point for such effort because it's designed specifically
to be an independent rules language for XML (as opposed to semantic rules
languages), and because it's not a standard yet and can be modified and
reshaped easily without worry about legacy or backward compatibility.
To explain why I feel that the current XForms model is not ready to take
the role of a rules language, I want to elaborate on some points I mentioned
earlier and add a couple more. These are my thoughts about what needs to be
modified in the model to prepare it for that role. And, honestly, and trying
to be as unbiased as I humanly can, I feel that the goal can be better
accomplished with a fresh start that tries to align itself with, but not
restrict itself to, existing specs:
1. Move some of XForms features from UI controls to the XForms model. For
example, dynamic enumerations (the itemset element) and error messages (the
alert element). This will allow the use of these features when a UI is not
available (or when a non-XForms UI is used). In XRules, everything is in the
rules model and equally available to UI and non-UI applications; so a Web
service that has no UI can still return user defined error messages.
2. Provide a mechanism for rule grouping and reuse. Since a form is usually
limited by what a user can handle on one page, the need for such mechanism
is probably not a requirement for XForms. However, once you break out of
that scope, you might have to manage documents with hundreds of rules (e.g.
a mortgage application). XRules uses the <ruleset> as a way for grouping and
also for rule reuse (just like functions in procedural languages).
3. Provide extensibility options that allow adding new types of rules in
addition to the <bind> element. For example, to validate key uniqueness or
referential integrity (for non xsd:ID keys). Here, one of the key design
goals of XRules is to allow adding new rules (in addition to other
extensibility mechanisms such as scripts, XPath extension functions, events,
and hooks into the host application). Also, XRules allows user-defined
properties that provide an excellent extension mechanism for a wide spectrum
of applications. I have a very good example of this use in the form of an
XML annotation application that I have found to be very useful in my work
with OAGI based schemas, and I'm planning to post it to the XRules group in
a couple of weeks.
4. Create a standardized format for communicating errors to the application
in XML (in addition to currently used methods). XForms obviously doesn't
need that since it communicates errors through events and messages, but once
you remove the UI component, that need becomes obvious. For that reason,
XRules specifies the exact format in which an XRules processor must report
errors (the XRules report format). This allows applications to communicate
errors as well as rules, and makes it possible to do local and remote rule
processing and still provide feedback to the user the same way.
5. Context Sensitive embedding in XSD. And by context sensitive I mean that
if you embed a rule under a <complexType> or a <simpleType> then it applies
to all nodes of that type. This addresses the common approach by many,
including vertical standards groups, of considering the schema as a central
repository where all constraints and rules must reside.
Regardless of the final outcome, I'll be more than happy to submit
requirements, use cases, and proposals to the XForms group. If there is a
formal process to follow, please let me know.
And, before I end my long rambling and go to bed, I just want to say
that I think XForms has an elegant design, and the more I read about it the
more I tend to like it.
Best regards,
Waleed
http://www.xrules.org
-----Original Message-----
From: Roland Merrick [mailto:roland_merrick@uk.ibm.com]
Sent: Monday, March 14, 2005 2:46 AM
To: Waleed Abdulla
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] XRules: Mind your own business rules
Greetings Waleed, if you feel that the XForms Core module is too coarse a
granule to reuse for your purposes then perhaps you would like to look at
the bind element and see if that would meet your need and if so why not
provide feedback to the XForms group that you would like to see it as a
module.
XForms uses XML Schema as its basic type validation scheme upon which can be
layered XForms constraints. The SChema types can be associated in three
ways, the "normal" schema one of associating a schema with the document, the
xsi:type approach or an xforms supplied feature of bind that allows at type
to associated with a node in a manner similar to xsi:type but without having
to change the document.
Regards, Roland
"Waleed Abdulla" <Waleed_Abdulla@xrules.org>
11/03/2005 17:12
To
"'Mark Seaborne'" <mseaborne@origoservices.com>, <xml-dev@lists.xml.org>
cc
Subject
RE: [xml-dev] XRules: Mind your own business rules
> -----Original Message-----
> From: Mark Seaborne [mailto:mseaborne@origoservices.com]
> 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).
I started reviewing ver 1.1 of the specs after Roland's comments. It's my
feeling that a language to express business rules deserves to be a first
class citizen in the standards world. If the XForms workgroup considers
expanding on their dynamic model (add rule grouping mechanisms,
context-sensitive embedding in XSD, standardized error reporting ...etc) and
branching out the effort into a separate standard that works equally well
with XForms and with other standards, then that would be something
wonderful. How about it W3C?
> 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
I'll read more about this, but what I know so far is that XForms uses the
XML Schema data types. Is there more to it?
> 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.
> 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.
That's the general plan. If there is enough similarity and compatibility,
convergence makes a lot of sense. I'll study this in more detail. Thanks
Mark and Rick for the pointers.
Regards,
Waleed
http://www.xrules.org
-----------------------------------------------------------------
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>
|
