Some thoughts about the XForms Future Features list

All,

Even with improved sound, it is not easy to follow the conversations
today so I am sending below a few comments about the "future features"
list [1], maybe for consideration on Wednesday.

We went through that list at Orbeon and thought a little bit about
what really matters to us, whether for 1.2 and 2.0, based on our
experience with XForms and our own use cases.

The current list of features on the Wiki is very large and we think
that it is necessary to focus on the really important features without
spreading our energy too much.

Note that I don't cover below some smaller features which are on the
list and which we agree should be tackled, e.g. features like those
under "Ease-of-authoring Patterns".

1. Components (on the XForms 2.0 feature list already). By this, we
    mean the form author-facing feature that allows creating reusable
    components using XForms markup, probably with the notion of local
    model(s) to hold local state and functionality. Use cases obviously
    abound for this and it in particular it seems that most large forms
    need reuse and componentization.

    Because this feature might be a lot of work (and it may simply be
    hard to decide how to do it, e.g. XBL or not), it probaly fits
    naturally within XForms 2.0, but its relative importance as a
    feature is high in our opinion.

2. XPath 2.0. (this is present on the feature list but too low IMO). I
    reiterate that we should get something out ASAP in this
    regard. This should be done pre-XForms 2.0 and even pre-XForms 1.2,
    possibly as a WG note on how to add XPath 2.0 support to XForms
    1.1. I believe that this is possible and that we should just do
    it. That work can then be integrated into XPath 1.2 and 2.0.

    I understand how this can be seen as related to other expression
    languages, but XPath 2.0 is clearly special: there is a clear
    upwards migration path from XPath 1.0 to XPath 2.0, which will be
    much easier than, say, introducing JavaScript as an expression
    language and/or JSON as a data model.

3. New UI events (this as a general feature seems missing from the
    list). As explained many times, we need a new architecture for UI
    events so that they are sent appropriately. As they stand, UI
    events cause too many issues and confuse users. We have already
    discussed the possibility, if fixing the current events is not
    possible, of introducing new ones and later deprecating the
    existing events. Use case solved with this include: events upon
    initialization, events in repeats, events upon controls becoming
    relevant/non-relevant, events upon instance replacement.

4. Attribute Value Templates for various XForms elements (somehow this
    seems not to have made it to the feature list). We have been
    discussing AVTs forever in various calls and f2f. This is an
    extremely convenient feature for form authors, and it solves in an
    elegant way the question of how to make attribute values
    dynamic. Several XForms implementors have experience with this. It
    needs to make it into XForms. This should make it into XForms 1.2,
    under "Ease-of-authoring Patterns".

    Optionally, AVTs could be supported on host language attributes.

5. XPath variables (this is in the feature list). The sooner we get
    this, the better. This solves numerous issues in a quite elegant
    way, including accessing enclosing context information, avoiding
    repeating XPath expressions, etc. This should make it into 1.2,
    under "Ease-of-authoring Patterns".

6. Dialogs (this is in the feature list). This is a perfect candidate
    for *standardization* because XForms implementors all have support
    for it. There is a reason for it which is that it is an extremely
    common UI pattern. It should therefore be done sooner rather than
    later and could fit under 1.2's "User Interface Patterns".

7. Event context information (this seems missing from the feature
    list). All events should have context information. This includes
    XForms events but also the DOM* events. Context information should
    include "target", etc. For UI events, there should be a way of
    accessing a control's information, including label/help/hint/alert,
    etc.

Finally, a minor point: I am not a big fan of the term "Rich Internet
Applications":

* I believe that people have now moved beyond this kind of names as it
   is clear that everybody does and will do "rich" stuff. We are not
   saying much by saying "rich", really. It even sounds passé in a way.

* It seems to evoke almost exclusively things like Flex, Laszlo, or
   maybe Silverlight.

Getting rid of the term "rich" may just be good enough, e.g. "XForms
1.2: Patterns for Internet Applications".

That's it for now :-)

-Erik

[1] http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 5 February 2008 23:04:58 UTC