Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XRules: Mind your own business rules
 Can't say I know much about XForms or XRules, but these suggestions sound quite sensible. The only comment I'd make is with respect to the statement that, "XRules allows user-defined properties that provide an excellent extension mechanism for a wide spectrum of applications." Rather than restricting properties to property-value pairs, just allow well-formed XML. This covers the property-value case and allows much greater complexity as well. -- Ron Waleed Abdulla wrote: > > 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
