Re: XForms 1.0: My Opinions

Hi John,

first of all, let me say how good it is to get another browser 
implementor aboard!

You can find my comments on your concerns inline. NOTE: these are my 
personal comments as an XForms browser implementor and not the Working 
Group's.

John Keiser wrote:
> 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.  ...

I was also first opposing to the large number of events, but then found 
out that the events are actually a good way to integrate to other 
languages. For example, we are able to mix SMIL+XForms, and everytime a 
field becomes invalid, we are able to launch a voice message  or a 
video, just by using SMIL 2.0's default functionality of catching events.

value-changed cannot be directly replaced by DOM mutation events, since 
the mutation happens in the instace, while the event is needed in the UI.

> - [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?

Only few (say 2) are important for authors, so I agree partly. But I 
really don't see much harm in exposing the others too. As processing 
steps they really make sense.

> - [4.3.2]: why do you need this and xforms-unfocus when you have 
> calculatable readonly and disabled properties?

Do you mean that there is no use case for setting focus programmatically 
to a certain form control?

> - [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?

In my implementation this is no-op, just because of the reasons you gave.

> - [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 :)

I have a demo, where I catch these events, and cancel them, thus 
disabling calculations from running. Then you can use the <recalculate> 
action to manually run the calculations.

> - [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.

I also do not see a use case, but again, I don't see harm in exposing 
this part of the processing model as an event.

> - [4.4.1] xforms-activate -> DOMActivate.  From DOM3 Events spec, "The 
> ...

I also think xforms-activate should be replaced with DOMActivate.

> - [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.

I share your concern here.

> - [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.

One significant need for these events is integration with other XML 
vocabularies.

> 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.

Switch satifies the XForms requirement for multi-page forms, so I think 
it is there to stay.

> 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 

I personally do not care too much either way. The only opinion here is 
that element syntax is better for extensibility, but you were not 
proposing to remove that.

> 4. [10] actions look like an attempt to define yet another (very) basic 
> scripting language in XML.  Why, when other scripting languages already 
 >
> 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>.

I do not completely agree. For instance <setValue> is easier to read and 
maintain than ECMAScript and is quite powerful because of XPath.

> 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 

Columns/rows is a layout thing that can better be expressed with CSS 
properties such as width & height;

> 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>.  

IMHO wrap attribute could be needed. XHTML forms does not have it, but I 
think the browsers still support a wrap attribute and it is used a lot.

Also the single line textarea could be good. For instance, what if the 
form author really wants the user to see the underlying data for a date 
and not an UI representation that he will get from <input>. On the other 
hand, this could be a CSS / other attribute on <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.  

I do not think it has, unless incremental="true" is set on the control. 
And even then it can decide how often it will send value-changing events 
(and update the instance).

> 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] 

There is an DOM interface for accessing the instance DOM, which helps a 
lot (e.g. insert/delete could be done with DOM access to the instance). 
Also there are functions corresponding to some actions.

> SUGGESTED CHANGES:
>  submitInstance(), resetInstance(), insert() and delete() need to be 
> there at the least.

I agree that submitInstance() and resetInstance() need to be added.

> 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.

I don't completely agree. It just defines that the help is similar that 
a modeless message, which is not too tightly specified in 10.1.12.

> 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"), 

IMHO a form author can always construct the instance data so that you 
don't have to write functions that depend on the entire tree, so I don't 
consider this a real problem.

Regards,
	Mikko Honkala, X-Smiles

Received on Thursday, 5 September 2002 04:33:46 UTC