XForms 1.2 and simplification versus XForms 2.0 triage

Well, I'd like to further prime the pump of getting from the bottom 
(things on the future features wiki) to the top (guiding principles, 
requirements) for 1.2 and 2.0.

I remain convinced we need two documents, but otherwise agree with 
Sebastian that any further increase in the number of net documents we 
produce will simply bog us down in process land.

To generate discussion, I put an initial triage of features into the 
telecon agenda, and I think we should move forward with that, 
recategorizing between 1.2 and 2.0 as needed or wanted by the group, and 
especially adding hierarchy to the list.  The parent nodes of features 
will be the so-called guiding principles.

One area that I partially missed in my triage were some of the wiki 
elements under XForms simplification (go to the bottom).  I actually got 
most of them, I just thought someone moved the whole batch into the 
"XForms Transitional" feature.  It now likes like I missed a few other 
listed features as well.  It turns out that my view of the future features 
was hampered by the shoddy network service here at the XML conference 
hotel combined with a crash of the W3C wiki server.

Anyway, I would like to start with that XForms simplification list because 
I think that *some* of the listed features are along the lines of what we 
have long been talking about for simplification, and which could be called 
"Simplify Glass-to-Data Forms Authoring".  Here's what I think falls into 
that category:

Highest Priority 1.2 features
-----------------------------
1) Make model optional
2) Add model item properties to UI controls (e.g. readonly, type and maybe 
calculate)
3) Allow submission elements without model
4) Allow instance elements without model (preferrably without interfering 
with the implicit instance generated for certain UI controls)
5) Add support for default values on UI controls without need of instance 
element

There are three features listed under XForms simplification which I think 
are not "Glass-to-Data Forms Authoring" and so they should be considered 
separately.  At least one of them feels much more like a 2.0 feature.

Possible 1.2 features
---------------------
6) Simplified repeat authoring by codifying common things needed when 
repeating (suggest medium priority)
7) Same model item property on same node, or perhaps just the constraint 
MIP (suggest high priority)

Neither of these is "Glass-to-Data Forms Authoring", but are instances of 
a more general concept of "Ease of authoring".  Still, they don't feel 
like fundamental shifts.

I would also suggest that perhaps the simplified repeat authoring is more 
likely to move from 1.2 to 2.0 because it is a bigger change to the tag 
set and the way we currently do repeats. 

Possible 2.0 features
---------------------
8) Add support for multiple expression languages.

This one really feels like it is a more fundamental shift because it 
reverberates through the whole processing model and how you might write 
pieces of the entire form.  Frankly, I would actually suggest that this is 
*more general* than "Alignment with XPath 2.0", or rather that XPath 2.0 
alignment is a special case of this feature.  I think we will get this as 
part of the refactoring that would also perhaps allow us to do JSON data 
with javascript referencing and calculations.

The rest of my triage sought to classify as 1.2 all features which seemed 
to fall into the "Ease of authoring" category, either for all forms or for 
certain kinds of form applications.  Here they are with a rationale:

Possible 1.2 features (Suggest High Priority)
---------------------------------------------
9) decimal-string() function - this is a hard requirement for financial 
apps due to the insufficient precision of double numbers.  It rounds to a 
certain precision past the decimal point.  Note that this cannot be done 
with "intelligent" UI controls in part because it is the underlying data 
that is choking up server tier apps, requiring either this fix or a fix on 
the middle tier, which as you know directly contradicts the XForms value 
proposition.

10) sumproduct() function - this is required for ease of authoring simple 
purchase order apps.  Right now, one has to create extra data layer nodes 
to hold row products so that a sum can be computed.

11) We should consider a better ability to both enclose and extract 
attachments from instance data.  Four of the future "features" seem 
necessary here:

- We need to be able to say that the upload control can gzip compress the 
upload content.  Also, although base64 or hexbinary encoding is done based 
on the node's datatype, we need to be able to compel base 64 and/or 
hexbinary encoding *without* the schema datatype assignment.  This is a 
"Glass-to-data" point.

- Observe that we can upload content which may be compressed and certainly 
is encoded, but we have no analogous ability to base 64 decode and 
decompress with file put submission.  We need to add those two 
capabilities to file put submission

- Once we can put the data out to disk in binary format, we need the 
analogous compress and encode on file get submission.

- We have the ability to get and put files, so we need the ability to 
present an Open or Save file browser dialog

12) Default trigger for form - this is ease of authoring and "Glass to 
Data"

The wiki also contains this kludge (added by me but only in desperation): 
Commit value on DOMActivate (enter) on input and select1 and select 
selection=open.  I would advocate removing this in favor of something 
direct.

13) Improvements to UI switching.  This is ease of authoring and also 
fixes 1.x design shortcoming that causes people to do data-driven 
switching without using switch.

- Model-driven switch with switch (case attr; xpath; result IDREF)
- Multi-case switch (case attr; xpath; result is IDREF list)
 
14) Simplified data manipulation actions

- Actions for various kinds of insert and delete operations in Appendix B
- Create action that is like an insert+setvalue but requires no origin 
template

15) mediatype on textarea to allow GUI edit of basic html (enriched text 
editing) - this gives our authors an ability to enhance the end-user 
experience for Web 2.0 applications.

16) Composable, componentized models; this is needed to simplify 
development of larger XForms

-  Allow src on model
- Allow model within model, where id on inner model is ignored and all 
contained models can talk to each other

17) Allow access to web services that return xml as encoded text
- allow xmlparse() function, whose result could be used as the origin of 
an insert
- allow xmlserialize() for analogous sending to such web services


Possible 1.2 features (Suggest Medium Priority)
-----------------------------------------------

18) Better control over submission progress and cancellation
- Ability to cancel submission
-  Submission progress events

19) Action (?) with ability to ask if subtree is valid; needed for better 
wizard support

20) Put ref or context on action element (ease of authoring multiple 
action scripts relative to same node)

21) Let @value override single node binding on output (ease of authoring 
an output that gets MIPs from ref node but calculates display value)

22) Put @context everywhere (or at least repeat and likely group and 
switch) 

23) Custom UI controls - describe ability to attach non-XForms UI controls 
directly to model OR describe how to associate non XForms controls with 
XForms controls

24) Aggregated controls that act like a single control

25) UI controls that can provide a subtree as opposed to a string

26) Tree control

27) Better DOM interface to expose only data manipulation actions (fuller 
DOM interface appears in 2.0)

29) Better expression of default values 

30) Wiki Markup for XForms (Creation of interactive content) 
 I believe this is one of those "killer app" concept to allow more 
sophisticated data collection in wikis


Possible 1.2 features (Suggest Low Priority)
--------------------------------------------
31) Action to cancel events, which can be conditionally run with @if

32) Add bind() function, only for XPaths in form controls and actions. 
Would we still need @bind?

33) Better control of external instance (e.g. @submission on instance)

34) Context info for user defined events 

35) Create a construct for actions that iterates over a nodeset 

36) Fix select1 so that it can allow multiple items with the same value to 
be selected simultaneously as well as one that restricts to only one item 
that matches. 

37) Submission some kind of better filtering than relevance that affects 
only submission and not the UI 

38) xforms-value-changed context info for node changed 

39) Recoverable 'xforms-link-error' on instance src failure

Possible 2.0 features (and beyond)
----------------------------------

Align with XPath 2.0
Consolidated Recalculate and Revalidate
XPath Function access to MIPs
Multiple constraints
Improved HTTP authentication
Refactor modules of XForms
Refactor schema support (allow pluggable schema, e.g. schema 1.1, 
schematron, relaxng)
Integrate with XML signatures
AVTs
Variables in XPath
XBL integration
User-defined model item properties
Dialogs
Close Form
Ability to indicate if something is wrong in non-selected 
case/non-relevant group
SCXML integration 
Multiple step undo (e.g. undo to last state) 
Form apps as components 
Multiple simultaneous uploads 
Generate and maintain data based on schema 
multiple schemas targeting same namespace (e.g. allow inline schema to 
augment external schema; similar to having the internal one import the 
external one). 
Drive UI (presentational) properties from data and calculates 
A document() function 
DOM interface that exposes all aspects of XForms to script


The final caveat here is that these are just my own opinions and just a 
first pass triage that will hopefully stimulate discussion about where to 
move various bits so we can begin to tackle requirements *and* FPWD 
documents for XForms 1.2 and 2.0.

Best regards,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer