[
Lists Home |
Date Index |
Thread Index
]
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.
|
