Advisory: Changed definition of validity to include "non-empty if required"

Hi Mark,

The working group recently decided to rescind an earlier decision in 
XForms 1.0 to remove "required but empty" from the list of conditions that 
produce an invalid result (and hence an xforms-invalid).

The latest editor's draft of XForms 1.1 linked from the WG web page 
contains changes to the definition of validity in Section 4 
(xforms-revalidate event) to reflect this decision.

This removed an inconsistency between the notion of validity used in the 
UI versus the one used in submission.

The prior decision to exclude "required but empty" from invalidity was to 
avoid an unpleasant user experience on form startup for those who style 
invalidity in a particular way and those who write handlers for 
xforms-invalid.

However, for those few who do hook xforms-invalid to show a message, the 
fact is that the processing model does not support dispatching 
xforms-invalid on start up anyway.  Furthermore, the working groupnow 
believes the styling concern was based on interpreting informative 
information about styling in Appendix G as if it were normative and 
complete.

For the sake of being "more informative" the working group resolved to add 
extra CSS pseudo-classes to the list suggested to implementers so that 
authors can style required-but-empty controls differently than those that 
are invalid for other reasons.

The working group also resolved that I should write you this email to 
inform you of the change because the changes are only being reflected in 
the 1.1 spec.  Most of the working group feels that 1.1 is pretty much it 
going forward, and so the working group prefers to avoid doing extra work 
to create a further edition of XForms 1.0 to reflect this change there as 
well.  However, the working group is aware that Picoforms in particular is 
focused on 1.0 development and would therefore like to provide this 
advisory about the behavior change to the definition of validity and its 
effects on styling and on the xforms-invalid event.  Please let us know if 
you require a 1.0 spec revision and test suite update for this advisory.

Best regards,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
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


----- Forwarded by John Boyer/CanWest/IBM on 06/04/2008 04:49 PM -----

From:
"Leigh L. Klotz, Jr." <Leigh.Klotz@Xerox.com>
To:
public-forms@w3.org
Date:
05/28/2008 11:39 AM
Subject:
value-empty is not enough




In [1] John and I took on the action to propose a :value-empty CSS 
pseudo-class.

In reviewing the editor's draft, section G.1 "Pseudo Classes" [2], I've 
been reminded that CSS pseudo-classes are by convention tri-state, so 
for each pseudo-class there should its negation defined as well.   All 
existing Pseudo-classes in G.1 are defined in pairs.  The reason for the 
tri-state is that the middle is not excluded; for example, host language 
elements not bound to instance nodes would be neither empty nor non-empty.

Therefore, I propose that we define :value-empty as a pair, and 
tentatively that we use :value-empty and :value-non-empty.
(There is precedent for the use of hyphenated words; for example, 
:out-of-range and :read-write.)

[1] 
http://lists.w3.org/Archives/Public/public-forms/2008May/att-0054/2008-05-21.html#ACTION3

[2] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#N89852

Leigh.