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

Re: Validation and optional fields

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Wed, 10 May 2017 12:22:56 +0200
To: "public-xformsusers@w3.org" <public-xformsusers@w3.org>, "Erik Bruchez" <erik@bruchez.org>
Message-ID: <op.yz0psipismjzpq@steven-xps>
I think you are right, and that we solved this problem the wrong way with  
the xf: datatypes.

Although a change would be backwards incompatible, it would only show up  
in cases where
the value is optional, empty, and the type doesn't include the empty  
value, which clearly shouldn't be an error (and current Forms have to  
program around). So I don't think that this is a problematic  
incompatibility.

So the new validity rules would be:
- the constraint model item property is true
- if the required model item property is true, the value is non-empty
- if the value is non-empty, it satisfies all applicable types.

Steven

On Tue, 09 May 2017 19:13:41 +0200, Erik Bruchez <erik@bruchez.org> wrote:

> 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 Wednesday, 10 May 2017 10:23:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 May 2017 10:23:38 UTC