Rationale
On October 20, 2009, XForms 1.1 became a W3C Recommendation. This means that it is time to think about what XForms 1.2 or 2.0 will look like.
This page intends to list what Orbeon thinks is the most important.
The idea is that most of the work should be one of standardization, based on implementors' experience. For reference, we have documentation on most Orbeon Forms extensions here:
P1 features
Component system
This is implemented in Orbeon Forms.A component system is crucial for XForms. It allows authors to build on top of XForms without growing the core XForms specification.
The main use case is implementing custom user interface controls. Components do not have to address extending or modularizing XForms models.
Requirements include, but are not limited to the following:
- Ability to implement custom controls, including those that leverage existing JavaScript widget libraries.
- Strong encapsulation, to maximize reusability.
- Ability to use local models/instances.
- Ability to follow the patterns of existing XForms controls, including single-node bindings.
Here are examples of custom controls you could implement:
- Controls for datatypes which have a native implementation, but where a custom appearance is required
- Custom control for entering an xs:date with dropdown menus rather than a date picker
- Controls for datatypes which do not have a native implementation
- Control to capture the xs:duration type if the implementation is laking this
- Controls which do not have a standard XML type
- Phone number control
- Currency input control
- Higher-level components
- Datatable
- Google Maps
- Accordion
- Autocomplete
- Custom/application-specific controls
- Reusable US address control
Since late 2008, Orbeon has started implementing a component system for XForms based on XBL 2. The experience has been positive and the implementation is now a central part of the Orbeon XForms engine.
XForms could very well come with a library of standard components.
XPath variables
This is implemented in Orbeon Forms.
Support for XPath variables, as implemented in Orbeon or similar, must be an integral part of the XForms specification.
XPath 2.0 support
This is implemented in Orbeon Forms.Support for XPath 2.0, as desired by implementors, must be part of the XForms specification.
Beyond the Orbeon Forms implementation, thoughts are needed to see if/how type information provided by XForms should impact XPath 2.0 evaluation.
Overhaul of UI (refresh) events
This is implemented in Orbeon Forms.We call refresh events the following UI events, as they occur during refresh:
- xforms-value-changed
- xforms-enabled/xforms-disabled
- xforms-readwrite/xforms-readonly
- xforms-optional/xforms-required
- xforms-valid/xforms-invalid
Refresh events must be revisited to be reliable. This is not the case as has been shown (
see email sent to public-forms mailing-listo on June 12, 2007). This is particularly important with the introduction of the component system, which must be able to rely on e.g.
xforms-enabled to determine that a control has become visible, etc.
Requirements:
- UI events must be associated with controls.
- UI events must be reliable:
- A value change event must fire if and only if the value as seen by the control has changed
- A MIP change event must fire if and only if the MIP value as seen by the control has changed
- Enhanced event context information
Reference:
Dialog control
This is implemented in Orbeon Forms.This might be done through the component mechanism, in which case it wouldn't have to be a core feature.
P2 features
This list includes many features already discussed by the WG, but some new ones as well:
- Core
- Flexible positioning of models and new model scoping rules (planned in Orbeon Forms)
- Standalone label, hint, help, alert elements with @for attribute (implemented in Orbeon Forms)
- Generalized @value attribute (implemented in Orbeon Forms)
- Generalized @context attribute (Forms WG wiki) (implemented in Orbeon Forms)
- AVT support on most XForms attributes (implemented in Orbeon Forms)
- Events and actions
- exforms:iterate or similar (Forms WG wiki) (implemented in Orbeon Forms)
- Context information for user-defined events (Forms WG wiki) (implemented in Orbeon Forms)
- Events dispatched to instance upon valid/invalid (implemented in Orbeon Forms)
- MIPs
- Custom MIPs (implemented in Orbeon Forms)
- Restrictions to MIP pointing to same node (Forms WG wiki) (implemented in Orbeon Forms)
- Dynamic initial value bind attribute (Forms WG wiki) (implemented in Orbeon Forms)
- MIPs in the view, i.e. directly on control elements (as per XForms "simplification" effort) (not implemented in Orbeon Forms)
- XPath functions
- Custom XPath functions (Forms WG wiki)
- case() function (implemented in Orbeon Forms)
- XML encode/decode, Parse, Serialize functions (Forms WG wiki) (implemented in Orbeon Forms)
- Sorting functions like exforms:sort() (implemented in Orbeon Forms)
- Functions to create elements and attributes (implemented in Orbeon Forms as xxforms:element() and xxforms:attribute())
- bind() function (implemented in Orbeon Forms as xxforms:bind()) (Forms WG wiki)
- Number and date/time formatting functions from XSLT (implemented in Orbeon Forms)
- eXforms relevant(), readonly(), required() functions (implemented in Orbeon Forms)
- valid() and type() functions (implemented in Orbeon Forms as xxforms:valid() and xxforms:type())
- Submission
- HTTP auth (Forms WG wiki) (username/password implemented in Orbeon Forms)
- Binary submissions (Forms WG wiki) (partly implemented in Orbeon Forms)
