- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Wed, 30 May 2007 14:28:43 -0700
- 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:28:56 UTC