Re: XForms 1.0: My Opinions

Mikko Honkala wrote:

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

Glad to make your acquaintance.  Browsers are important :)

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

The events you speak of are useful ones.  I think we should keep them, 
as they are wonderful things.  I am simply arguing we should remove the 
ones that are not useful (about 1/3).

value-changed is useful in the UI for people who want to catch changes 
as a result of a control, so I didn't put it on the strike list ... 
since most people will only have one control per element, it's all right 
to deal with.

That's actually a good point; do we deal with what happens when multiple 
controls reference the same data?  I suppose updates to the data from 
one control have to be caught and replicated into others.

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

The processing steps make sense; the events do not.  And especially at 
this early stage in the spec I don't think we should say "it doesn't 
hurt anybody" ... we should be asking "why do we need it"?  We should be 
ruthless in eliminating things which have no use.

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

Isn't that what focus() is for?  Events do not exist to emulate 
functions.  They exist to tell you that an event has occurred, or to let 
you cancel or attach your own action to an event.  Let's not go down the 
path of making people fire events to cause things to happen (unless they 
want to simulate a UI event, for example).  The <action> model is better 
than that, even.

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

Thus I feel it should be removed--and even if we change the spec to 
allow things like textarea to not always reflect instance data, this 
should not be an event.  It is implementation-dependent and nothing that 
event handlers need to catch.

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

OK, I can see that point :)  I can also see JavaScript handlers might 
want to do calculation or validation themselves on xforms-recalculate.

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

Same as above--the harm is done by adding something that is unnecessary.

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

I don't grok, could you explain further?

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

 From the requirements doc: "It should be possible for a form to be 
presented as two or more pages. This requirement permits the form to be 
treated as a single unit or as several parts. The form's logic should 
apply regardless of how it is split up."

This requirement can be satisfied in XHTML, and IMO should be.  Every 
requirement in XForms does not have to be specified in XForms.  XForms 
has done its job by making it possible to use different sets of controls 
on different parts of the instance data at different times--another spec 
should decide when to show those controls.

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

I'm not convinced on the point of <setValue> but if a significant 
portion of forms are going to use it then it's fine (I have a feeling 
they will not, but it remains to be seen).  There is DOM access to XPath 
too.

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

I think you are right; but CSS is going to also need width-in-characters 
to give people functionality they expect.

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

Exactly!  Either way works, I suppose.

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

 From [8], paragraph 4:

"Form controls when rendered display the underlying data values to which 
they are bound. While the data presented to the user through a form 
control must directly correspond to the bound instance data, the display 
representation is not required to exactly match the lexical value. For 
example, user agents should apply appropriate conventions to the display 
of dates, times, durations and numeric values including separator 
characters."

Perhaps the spec should be updated to state that a control can 
temporarily render a different value as long as it later updates 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.

Aye, I can see it in there, it is missing the method names, however, and 
there only appear to be 4 functions as opposed to more than 10 actions.

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

It actually says it has to be the same as a modeless message, not just 
similar.  modeless message could be a suggested implementation, but I 
don't think there should be any constraints.  Let's let the browser 
implementor put help in a special help space if they want, even if 
modeless messages happen in popup windows.  Let them experiment.

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

A form author can't always construct the instance data the way he wants 
:)  One of the major applications I see for this is XML interoperability 
and SOAP, which means your data format is fixed by the person you are 
sending data to.

--John