W3C home > Mailing lists > Public > public-xformsusers@w3.org > May 2017

Validation and optional fields

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 9 May 2017 10:13:41 -0700
Message-ID: <CAAc0PEWT1nmL+-OV-g-KkWtgQ5V8XEi4OoiVSVrJi6TWmkJX5Q@mail.gmail.com>
To: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
All,

XForms says this:

> An instance node is valid if and only if the following conditions hold:
>
> - the `constraint` model item property is true
> - the value is non-empty if the `required` model item property is true
> - the node satisfies all applicable types (including those associated by
the `type` model item property, by an external or an inline XML Schema, or
by `xsi:type`).

There is no indication that an optional-but-empty field should be
considered valid. But it seems to me (and to a number of our users who have
been bitten by this) that this would be reasonable logic.

For example, a common use case is to say: "This field is optional, but when
it is not empty it must be a positive integer."

Because of this, XForms introduced special `xf:*` types, like `xf:integer`,
so that type validation doesn't get in the way of optional fields. So with
the example above, right now, you can use `xf:integer` and that is fine (at
the cost of more types defined by XForms). But when it comes to
constraints, that's where you get more work. For example you write
something like:

    <xf:bind
        ref       ="quantity"
        required  ="false()    (: or just missing as `false()` is the
default :)"
        type      ="xf:integer (: so the field remains valid when empty
  :)"
        constraint="normalize-space(string(.)) = '' or . gt 0"/>

In other words, you have to think to handle the case where the value is
blank, when you have already told XForms that the value could be blank!

Instead, you could write:

    <xf:bind
        ref       ="quantity"
        required  ="false()    (: or just missing as `false()` is the
default :)"
        type      ="xs:integer (: keep the standard type
   :)"
        constraint=". gt 0     (: just focus on the constraint logic
   :)"/>

Clearly, a change like this would be backward-incompatible. But it might be
something to consider.

Could an `optional="true()"` attribute, which would be the dual of
`required="false()"`, introduce that new behavior? Just thinking as I type
here!

-Erik
Received on Tuesday, 9 May 2017 17:14:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 May 2017 17:14:36 UTC