Proposal: Fix for definition of valid

On the telecon today, the issue of reversing the prior decision of the 
working group and include "required but empty" in the list of things that 
causes a node to be invalid.

This would cause the following two edits to the spec:

1) Add a third condition to node validity that says "the required model 
item property is false or the node value is non-empty".  This would occur 
in the xforms-revalidate event, where the definition lives (
http://www.w3.org/TR/xforms11/#evt-revalidate)

2) The submission chapter says that submission validation includes 
validity according to the definition in xforms-revalidate plus checking 
required-but-empty.  We would remove the required-but-empty part because 
it is included in the definition via #1 above.

I believe that the concerns which caused that erratum change to XForms 1.0 
Second Edition are largely unfounded and in fact even this change back to 
the prior definition should not have an impact. 

The main concern, as I recall, was that xforms-invalid might get 
dispatched on form start-up before the user has a chance to interact with 
the form.  However, xforms-model-construct has always stipulated that it 
does not issue xforms-refresh, therefore there is no initial 
xforms-invalid event that would be issued for a control bound to a node 
that is required but empty.

Since the purpose of the change was to ensure there would be no 
xforms-invalid event on startup for controls bound to required-but-empty 
nodes, and since other aspects of the processing model ensure that these 
events do not occur, changing the validity definition back should not 
affect on conformant implementations.

There are two other issues that I would like to suggest should remain as 
separate topics, i.e. proposals related to them should be discussed on 
separate threads and should not get in the way of making this fix:

1) Some have wanted a better way to use required="false()" to indicate 
that validity failure should not result in xforms-invalid if the reason 
for the failure is that the node is empty.  Doing this directly raises 
challenging questions like whether this should apply even if constraint 
fails.  So, instead, we solved this problem in a different way already by 
adding xforms types that union xsd types with empty string.  Furthermore, 
schema authors are encouraged to use the same simple technique, which can 
also be done to existing schema via import.  This is why proposals for 
alternatives should be handled separately.

2) Some have wanted the standard form control notification events to apply 
upon initialization of form controls.  This could be done but some care 
would be needed.  For example, we would need to expressly accommodate the 
above mentioned requirement that xforms-invalid should not occur on 
initialization of a form control if it is bound to a node that is required 
but empty.  OR, xforms-invalid would need to have context information 
indicating which failures occurred.  In any case, this should be taken up 
as a separate issue since the working group already agreed it is a future 
requirement, not a requirement for 1.1.  Therefore, I would prefer it if 
this issue also did not get in the way of fixing the above problem 
identified by Erik in [1].

[1] http://lists.w3.org/Archives/Public/public-forms/2008Apr/0118.html

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