Re: XForms 1.0: My Opinions

Mikko, good talking to you :)  Comments inline.

Mikko Honkala wrote:

> Hi John,
>
> you can find some additional comments inline.
>
> John Keiser wrote:
>
>> Mikko Honkala wrote:
>
>> 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.
>
> The disagree here seems to be that XForms has defined it's processing 
> model using events that can be seen in the DOM. I think Raman 
> elaborated more about this in his recent email.

OK; I think this comes down to a more fundamental disagreement of how 
events should be used :)

>>>> - [4.3.4]: xforms-refresh: if all form controls are required to 
>>>
>> 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.
>
> The point is that the current spec gives possibility of cancelling 
> xforms-refresh, and thus suggests that you can cancel UI refreshs. 
> There might be an use case for this.

However, even if there is a use case for this, it leaves us with a bad 
situation for a spec, one where most specs do not implement the event 
or, if they do, it is a noop.  Cancelling the refresh event will do 
nothing for them.  This event should at the least be made explicitly 
optional or it will be misleading.

>>>> - [4.4.11-16]: xforms-readonly, -readwrite, -disabled, etc. should 
>>>
>>> ...
>>> One significant need for these events is integration with other XML 
>>> vocabularies.
>>
>> I don't grok, could you explain further?
>
> First of all, it is easy to say that a language can define an XForms 
> compliant control by listening to these events and acting accordingly. 
> Secondly, an aurhor may want to listen to these events and do things 
> according to the state changes. E.g. use SMIL's intrisic capability of 
> playing a sound when a xforms-disabled event fires.

I can see that first point. It seems to me that another XML vocabulary 
will not be able to make itself receive these events unless XForms knows 
about them.  Perhaps when they are bound to the instance model using 
xforms:bind or xforms:ref XForms could then begin to send events to 
them.  There would have to be an unbinding mechanism as well to let 
xforms know to stop sending said events.  This is a good point; I will 
have to cogitate more.

Listening to events I definitely agree with--which is why I didn't say 
that all events should be removed :)  Just those which don't have use 
cases.

>>>> 2. [9.2.1] <switch> is a layout-oriented (it seems to be used to 
>>>
>>> Switch satifies the XForms requirement for multi-page forms, so I 
>>> think it is there to stay.
>>
>> 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.
>
> XForms is to be used with different UI vocabularies, such as SVG as 
> well. You are implying that the requirements for both XForms and XHTML 
> were wrong. It's probably too late to change those. (I still see your 
> point and agree somewhat).

I don't think personally that 1.0 is too late for anything.  We don't 
have enough implementation experience overall or enough users to say 
that 1.0 will be the final final spec.  We need to decide these things 
based on their merit, though; and I think multi-page forms can be 
satisfied better and more generally in another layout-oriented language. 
 XForms's requirements do not say that XForms itself has to provide an 
element that allows you to split a form across pages.  It says (if one 
wants to read it perversely :) that it has to support this capability. 
 So another language could define the capability and XForms must be done 
in such a way as to seamlessly work with it.

>> 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.
>
> I have used setValue in most of the demos I've created, so I do not 
> agree. It has proven a quite powerful function of XForms, and I doubt 
> that XForms would be the same without it.

I bow to your experience.  I will withhold personal judgement on this 
for now, until I have had more experience with JavaScript-enabled XForms :)

>>>> 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.
>
> It could help UI interoperability to have at least some rules here.

IMHO, rules should be made abstract, however; for example "help should 
be more obvious, more 'in the user's face' than a hint" rather than 
"help should always be rendered the same as this other UI construct we 
have created."  This is overall a minor point, however.

>>>> 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./
>
> By the way, does it help your use case that XForms deliberately allows 
> self-reference in XPath calculations (see app. D)?

I am going to have to punt to Jonas on this for now.  He does have a 
better feel for this than me.  I think he's planning to write up his 
concerns on the dependency model to the list.

Many happy returns,
John