W3C home > Mailing lists > Public > www-forms-editor@w3.org > June 2007

Re: Required but empty

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Mon, 04 Jun 2007 11:07:26 -0700
Message-ID: <466454DE.5060001@orbeon.com>
To: public-forms@w3.org
CC: www-forms-editor@w3.org

All,

A follow-up to this question:

I find that in 1.1 we do have some better text specifying what it means 
for a string to be empty. This is in "6.1.3 The required Property"

   "The value of the bound instance data node must be convertible to an
    XPath string with a length greater than zero."

Therefore I suggest that in the two places where we say "required but 
empty" we clearly refer to section 6.1.3. The occurrences are in 
sections "4.3.5 The xforms-revalidate Event" and "11.2 The xforms-submit 
Event" (point 3). More precisely, I suggest that:

   "required but empty"

be changed to:

   "required but empty (as specified in 6.1.3 The required Property)"

This is still not 100% correct as 6.1.3 in fact define "non-empty" 
instead of "empty" ;-) But at least this will point the reader to a 
formal definition of emptiness.

And of course this does not address the issue that this definition of 
emptiness is not very useful as I attempted to show below.

-Erik

[1] http://www.w3.org/TR/xforms11/#model-prop-required

Erik Bruchez wrote:
> 
> John, Ulrich:
> 
>  > I agree with Ulrich.  The meaning of empty string is clear, and a
>  > string with spaces in it is not empty because it has spaces in it.
> 
> Ok, that's what I thought, unfortunately ;-)
> 
>  > I do agree that this is different than what a user-friendly
>  > interpretation might mean, but this would not be the only place where
>  > such technicalities cause us a little grief.  Here are a few other
>  > favorites:
>  > 1) having to say true() and false() rather than true and false
>  > 2) Having empty string not be the same thing as zero in XPath
>  > mathematical operations
>  > 3) Empty string being unacceptable lexically for many schema datatypes
>  >
>  > Still, these don't mean our issues are ill-defined.  Just that right
>  > now a form author would have to do more work to address the
>  > situation when there should be no distinction between two things
>  > like whitespace string and empty string.
> 
> I think that this comes down to whether our current definition of
> "required but empty" is actually useful in a form application. I am
> contending that it is not very useful at all.
> 
> There are a few uses of the "required" MIP I can see:
> 
> 1. Use it to visually style form controls to mark that they are
>    required. You may do this with a different color, with a little "*"
>    next to it, etc. This is actually just fine as is at the moment.
> 
> 2. Use it as a constraint on the actual data. This is what we do at
>    submission time where "required but empty" data prevents submission
>    (unless validate="false").
> 
> 3. Style controls as "required but empty" to alert the user that a
>    required field must be filled out. I don't think XForms recommends
>    any CSS to do this at the moment, but in Orbeon Forms we allow
>    this.
> 
> #2 above is where I think there is the main issue (#3 suffers from the
> same issue with the definition of "empty", but let's skip this one for
> now). If a user by mistake or on purpose enters blank spaces in a
> required first name field, the field still satifies the condition
> "required". I think that in 99.9% of the cases, this is not what you
> want.
> 
> I know, you can use types and constraints to enforce this
> condition. But that's exactly my point: I may as well never use the
> "required" model item property, because I will always have to use a
> schema type or a constraint to express that the field must contain a
> non-blank value anyway.
> 
> This limits the practical uses of the "required" MIP in my
> opinion. Certainly, it makes #2 above not very useful as a
> constraint. Or am I missing something?
> 
> If it was up to me, I would look at solutions such as:
> 
> 1. Redefine "required" to require one non-whitespace character.
> 
> 2. Allowing the form author to express how "required" is computed. For
>    example, a form author could be content with expressing that
>    whitespace content still satisfies the "required" condition, while
>    another author could be stricter and say that a field must contain
>    at least one non-whitespace character to satisfy requiredness.
> 
> -Erik
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Monday, 4 June 2007 18:07:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:15 GMT