Re: XForms 1.0: My Opinions

Hi John,

you can find some additional comments inline.

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

Yes. Multiple controls can bind to the same instance data. When one 
control updates the instance, the others must be updated as well. I 
agree that there should be at least an informative note about this in 
the spec.

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

Ok. I see your point.

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

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

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

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

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

That part of the spec does not tell how often the instance must be 
updated. But I agree, the spec might be little clearer on this.

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

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

Cheers,
	Mikko

Received on Friday, 6 September 2002 05:27:58 UTC