W3C home > Mailing lists > Public > public-forms@w3.org > May 2008

Re: Proposal: Fix for definition of valid

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 1 May 2008 11:23:30 -0700
Cc: www-forms@w3.org
Message-Id: <7F174A60-1ADC-4B03-94FE-D02F9FEFE1AC@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>

John & all,

I believe that if a concept confuses even XForms experts (including WG  
members), and if we can't even find a good rationale for that  
confusion in the first place, then a change is badly needed!

In other words, I think that this change is a very welcome  
clarification, and it has the full support of Orbeon.

-Erik

On Apr 30, 2008, at 11:00 AM, John Boyer wrote:

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

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Thursday, 1 May 2008 18:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:48 UTC