XForms 1.0: My Opinions

Greetings,

I have been reading the XForms 1.0 draft.  It does most of what it set 
out to do (an amazing accomplishment): it fixes forms, and adds adds a 
lot of important stuff to the picture.  But I am concerned that it has 
some real problems that will significantly slow its adoption among web 
developers.

The major sections of the XForms Requirements that I think the spec does 
not completely fulfill are 2.3 (Migration from HTML 4), 2.4 (Ease of 
Authoring), and 2.7 (Scripting Interfaces).  This is due largely to an 
oversaturation of events, lack of adequate facilities for scripting 
(interfaces and hooks for scripting to start, and much of the "action" 
model being better suited to true scripting languages), and general 
emphasis on elements rather than attributes.

My interest here is not idle.  First, I am the primary maintainer of the 
form implementation in Mozilla/Netscape, and I am acutely aware of many 
of its flaws (most of which XForms remedies).  Second, I am interested 
in implementing XForms in Mozilla/Netscape, and I want to make sure that 
what I implement will not frustrate the web developers the browser 
supports :)  But if things are open to change even after CR, which it 
seems it is, then I'm glad to jump into the fray and implement in 
parallel with the changing process.  I wish I could have gotten involved 
in the process earlier, but I only began working on Mozilla less than a 
year ago.

Some of the suggested changes here may seem a little extreme (it removes 
a lot of events and actions), but my feeling is, start small and build 
up after the first release.  As my grandmother said of cooking, "you can 
always put more ingredients in, but you can't take them back out."


WHAT I LIKE

1. Separating form control layout from the model fixes a major problem 
in forms: the unnecessary requirement for controls to be contained in 
the <form> tag.

2. Making it possible for the server to validate using the same rules as 
the client is huge.

3. Allowing instance data to be carried across pages is a huge win.  The 
mechanism to do this is not very well addressed here, but I don't feel 
itshould be addressed here.  It is entirely a presentation issue, unless 
you actually want to be able to access the same instance data across 
documents.  It could be handled in XHTML, for example, with a <wizard> 
or <tab> element.  Daniel Glazman tells me the :target selector may help 
with this.

4. The addition of an editable combobox will make data entry developers 
drool.

5. The spreadsheet idea is really cool.  Computational dependencies are 
going to be a really difficult point, however, as discussed in #12 in 
the next section.

6. The ability to submit arbitrary XML is a real boon, enabling SOAP 
apps to take data from a form, which was probably part of the intent :)

7. The whole hint / help thing is pretty cool.  I like the ability to 
easily specify help for various controls--something that different apps 
have been doing differently (or not at all) since time immemorial.


MY CONCERNS

1. There is a huge number of events in the system that adds more 
confusion than it helps.  Some of these events, such as xforms-activate 
and even to an extent value-changed (mutation events), duplicate 
functionality in the DOM3 Events module.  Others seem unnecessary or 
redundant.  Events do not exist to expose every single step of an 
implementor's algorithm.  Events are meant to be useful hooks for 
scripts.  This seems like a good rule: "don't add an event unless 
somebody can think of a good conceivable use for it."  Please also 
remember that mutation events targeted at the instance data should take 
care of even more things than this spec takes care of.

- [4.2]: xforms-model-construct and friends: is there a benefit to 
having these 5 stages of initialization being transparent to the web 
developer?  Perhaps some of these could go away, such as 
xforms-model-construct, xforms-model-initialize-done and 
xforms-ui-initialize?
- [4.3.1]: next and prev can be useful for a control to stop focus from 
being changed, but how about coalescing them into xforms-focus -out to 
handle other things like the user trying to click on another element? 
 This also means they won't do next and forget prev.  I am a little 
dubious about the usefulness of this overall given that we have 
value-changed already, but implementation stage will tell.
- [4.3.2]: why do you need this and xforms-unfocus when you have 
calculatable readonly and disabled properties?
- [4.3.4]: xforms-refresh: if all form controls are required to 
represent the value in the instance data at all times, as [8.1.1] seems 
to say, how can this be anything but a no-op?  If it is supposed to be 
in response to when a particular piece of instance data is modified in 
the DOM, shouldn't that be handled by the form controls listening for 
changes?
- [4.3.5, 4.3.6]: xforms-revalidate, xforms-recalculate: do we *really* 
need these?  Does script need to catch them?  I can see potential uses 
hanging at the edge of my intuition, so perhaps :)
- [4.3.7] xforms-rebuild: we definitely don't need to catch this event 
in script.  I can see the last two, but not this one.
- [4.4.1] xforms-activate -> DOMActivate.  From DOM3 Events spec, "The 
activate event occurs when an element's default action is activated, for 
instance, thru a MouseEvent 
<http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-MouseEvent> 
click or a TextEvent 
<http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-TextEvent> 
textInput."  From XForms 1.0, "Dispatched in response to: the "default 
action request" for a form control, for instance pressing a button or 
hitting enter."  They read the same to me.
- [4.4.5]: xforms-scroll-(first|last): I am concerned about this but I 
haven't built a good enough repeat model in my head to determine if I 
like them or not.
- [4.4.11-16]: xforms-readonly, -readwrite, -disabled, etc. should only 
be fired when the state changes.  If that is granted, then they can just 
be handled with DOM mutation events (perhaps these are too hard?).  If 
that is not granted, at the least readonly/readwrite could be 
readonly-changed, disabled/enabled could be disabled-changed, etc. 
 Still I recommend removal altogether until a significant need is shown.

SUGGESTED CHANGES:
- Remove xforms-model-construct, xforms-model-initialize, 
xforms-ui-initialize.
- Replace xforms-next and xforms-prev with xforms-focus-out
- Remove xforms-focus.  (readonly and disabled are sufficient to prevent 
focus from changing into a control.)
- Remove xforms-refresh and xforms-rebuild.
- Rename xforms-activate to DOMActivate.
- Remove xforms-readonly, xforms-readwrite, xforms-disabled, 
xforms-enabled, xforms-required and xforms-optional

2. [9.2.1] <switch> is a layout-oriented (it seems to be used to specify 
a "wizard" interface or split things up for a PDA, or to specify a set 
of layout stuff that will appear only if a particular expression is 
true).  It belongs in a layout-oriented spec such as SVG or XHTML.

SUGGESTED CHANGES:
- Remove <switch> / <case>

3. The syntax is generally too element-oriented and does not allow 
attributes in enough places; [8.1.10] <select*> is particularly bad 
about that.  This makes it hard to write.  [8.3.3] "label" in particular 
needs to be specifiable as an attribute (like <trigger label="Click 
here">).  It's too commonly used to require the bulky element syntax. 
 This will make things more readable and easier to write.

SUGGESTED CHANGES:
- Allow "label" and "hint"  as an attribute on all form controls 
(perhaps say "elements take precedence over attributes where there is a 
conflict")
- Allow "value" as an attribute in <item>

4. [10] actions look like an attempt to define yet another (very) basic 
scripting language in XML.  Why, when other scripting languages already 
exist?  I can see the need for the most common of these actions, but I 
think only the most common ones that would be done in a <trigger>--send, 
reset, and some sort of script (unless there is an easy way to specify 
event handlers in XForms / XML without resorting to a JavaScript onLoad 
handler?).  Let uncommon actions be done in script--we don't need two 
versions of every function, and all functionality needs to be in a DOM, 
so <action> is the one where we should be parsimonious.  I hear the rule 
of thumb in the WG is 80%/20% ... that's an admirable goal, but I doubt 
80% of it can be dealt with, period.  Many buttons are just too custom. 
 A more reasonable goal is "the most common functions people will expect 
to have in the browser."  This includes reset and submit by default (to 
migrate from HTML), and probably includes insert and delete.  script can 
handle the rest.

SUGGESTED CHANGES:
- Remove all actions but submitInstance, resetInstance, insert, delete, 
and script.  Note that other actions may be common enough to meet the 
threshold--this is just my gut feeling of the most common actions for a 
<trigger>.

5. [8.1.4] textarea doesn't seem to have attributes for columns/rows 
(perhaps this is a CSS thing) ... a question that needs to be asked is 
whether we need wrap="hard" in textarea, which affects both layout and 
data.  Also, textarea should also be able to encompass both single-line 
and multiline text controls for people who really just want a text 
control for input rather than a general "who knows what you'll get" 
<input>.  I must say, also, that I am a little concerned about 
<textarea> having to reflect the current value in the instance data at 
all times.  Given the way soft wrapping works, a proper implementation 
is going to have to do a somewhat expensive operation (O(n) where n is 
the number of lines in the control--and a string copy) on every 
keystroke.  We can work this out as time goes by, though--perhaps for 
<textarea> the instance data isn't required to get updated immediately 
on every keystroke, but only when value-changing occurs.

SUGGESTED CHANGES:
- Add a "wrap" attribute specifying that the current value in the 
instance data should contain the carriage returns in the textarea.  This 
could be easily saved until the next version, as it is an addition.

6. Putting xforms controls into the xforms namespace and not providing 
for the vast majority of form developers who are going to be doing all 
this within an xhtml layout seems bad to me.  We need to place the new 
controls in the xhtml namespace.  Peppering their layout code (for that 
is truly what the form controls themselves are--specifiers indicating 
presentation and UI on top of some data) with "xforms:" or even "f:" is 
going to be a turnoff for developers.  This is a minor point, though, 
and can be addressed in XML itself by supporting multiple default 
namespaces with DTDs.  I understand somewhat the desire to keep it out 
of xhtml namespace, if this is useful in SVG.

SUGGESTED CHANGES:
- None.  I have heard the XHTML WG is considering a way to handle it. 
 We'll look and see.

7. I don't see any scripting interface here.  Perhaps this is bound up 
in the decision to have such a rich action model, or perhaps there is a 
planned XForms DOM?  [7.2] 
(http://www.w3.org/TR/xforms/slice7.html#expr-instance) is missing 
method names, but what it even shows there does not handle everything it 
needs to.  Particularly, everything that is currently in an action needs 
to be do-able in script.

SUGGESTED CHANGES:
- Create a full-featured DOM (this is too big a task for me to specify 
completely here, but at the minimum most of the stuff that is currently 
in <action> tags should be do-able via a DOM interface somewhere). 
 submitInstance(), resetInstance(), insert() and delete() need to be 
there at the least.

8. [8.3.4] help is overspecified.  If an implementor wants to have a 
"help window" section that displays help text, they should be able to.

SUGGESTED CHANGES:
- Don't say anything about how help is implemented in a user agent.

9. [Appendix D] Jonas Sicking <sicking@bigfoot.com> has pointed out to 
me that there are many very basic cases that you cannot form a real 
non-circular dependency tree--many XPath functions deal with nodesets 
that "depend" on the entire tree ("average of all valid numeric 
descendants of element root"), thus making any other dependency but that 
one create a circle.  You could recalculate dependencies every time you 
recalculate for these cases, though, and alleviate that problem. 
 Further, XPath selectors can select nodes where attribute=<specific 
value>, which makes their dependency continuously change over time, even 
during the calculation stage.  Dependencies would have to, in that case, 
be recalculated after each calculation step, and choosing which nodes to 
calculate first would be a rather complex process.

SUGGESTED CHANGES:
- this is more of a concern than an issue requiring resolution.  I 
suspect during implementation in Mozilla (which has a lot of XPath in 
it) we will know better whether and how it will fully work.

Regarding the XML Schema dependency: I hear that XML Schema is "bloated" 
and wanted to say that I just plain don't have enough experience with 
XML Schemas to know, so I haven't commented on it.  I am glad that 
XForms removed the plethora of XML Schema-inspired date types that were 
in the earlier version of the spec, however.


Thanks to everybody involved for XForms.  I hope this is taken in the 
spirit in which it was intended: to help make things better.  I would 
very much like XForms to succeed and be something web developers 
consciously choose.  Let <form> go to its grave :)

Cheers,

John Keiser
Netscape Forms Developer