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/