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

Re: Required but empty

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 30 May 2007 14:28:43 -0700
Message-ID: <465DEC8B.2090008@orbeon.com>
To: public-forms@w3.org
CC: www-forms-editor@w3.org

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 Wednesday, 30 May 2007 21:29:02 UTC

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