Re: Non-eventable and other thoughts

Hi Erik,

It's the documented behavior of non-relevance that the entire group spent 
a *long* time defining and ultimately issued as a W3C recommendation.

The intent was to *support*
1) the early use cases around simple xforms-invalid handlers would work as 
expected
2) the technical requirement that the user interface reflects the data 
model, including when the user styles non-relevant controls as disabled 
rather than invisible or not displayed
3) implementors having the freedom of action to decide whether the events 
were dispatched (so we *clearly* stated what would happen to the form 
author's eventing markup, rather than what implementations would do, when 
a control became non-relevant).

Some form authors may want to create actions that attempt to implement 
parallel data mutations, and we have *clearly* told them that the 
operation of those actions is *not* expected when the control is 
non-relevant, so I don't think that the forms you are describing exist in 
the wild right now.  However, we do have no small number of forms deployed 
that *do* depend on the above capabilities supported by the 
Recommendation.

So, now, in the post-1.1 timeframe, we have exhaustively considered all 
additional use cases and found that there are two other technical 
requirements we would like to be able to meet:

1) completely shut off non-relevant controls so that they cannot be styled 
and are otherwise unavailable to the render/presentation layer.  Thus, 
implementers could handle them as if they did not exist.

2) do not shut off the eventing of non-relevant controls, so that 
assessments of status such as validity could be determined based on 
analysis of the "full" user interface that could possibly be accessed by a 
user.

I really like both of these alternatives, and even wouldn't mind if one of 
them, such as #1, became the default.  However, I would find it 
unacceptable to address these new use cases in a way that discontinues 
support of use cases that are already in use and supported by the 
recommendation.  Like everyone in the standards community, I count on 
features that have become standardized and have released products that 
offer the features and customers who now use the features.

For these reasons, I feel it would be better for us to continue focus on 
the progress made at the face to face meeting to add the new, desired 
features by the simplest syntactic means such as were discussed earlier 
today.

John M. Boyer, Ph.D.
IBM Distinguished Engineer, Interactive Web Applications and Documents 
IBM Lotus Forms Architect
Workplace, Portal and Collaboration Software
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw






From:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
11/05/2010 11:25 AM
Subject:
Re: Non-eventable and other thoughts



All,

After today's talks, I am still wondering whether besides the backward
compatibility requirements, we need that no-events mode.

I think one of the arguments that was mentioned for the initial
rationale of this feature was that as a form author having event
listeners say on a group around something that is not relevant, you
might not expect events to be dispatched purely based on the fact that
there is some kind of expectation that something non-relevant is kind
of disabled.

Which would be fine, except for the other requirement which is that
the user interface updates values. But if you don't have events, that
requirements of the UI updating properly fails in many cases. Consider
for example the following scenario:

<xf:group ref="node-which-can-be-non-relevant">
    <xf:input ref="amount">
        <xf:setvalue ev:event="xforms-value-changed" ref="../tax"
value=". * 0.1"/>
    </xf:input>
    <xf:output ref="tax"/>
</xf:group>

Basically, any user interface that uses events to update other aspects
of the user interface would fail when non-relevant. So the no–events
mode would only make sense situations where the UI is not defined this
way, which is a big restriction.

The bottom line is that we might have to discourage form authors from
using this mode or things might not work as expected, and that makes
it an unsatisfying feature.

I think, again besides the backward compatibility requirements, that a
stronger case must be made for the no–events option.

-Erik