Re: Validation and optional fields

So I would like to decide this at the next call.

I think it is a great solution, and we should adopt it in one way or  
another.

As Erik points out, we have two options:

1. adopt the new rule, and bite the bullet and say that indeed it is not  
completely backwards-compatible, but they are mostly edge-cases.
2. keep @required as-is, possibly deprecated, and introduce @optional,  
which introduces the new rule (but the other way round).

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.

Please make your preferences known, and have a decided opinion ready for  
Wednesday.

Steven


On Wed, 10 May 2017 12:22:56 +0200, Steven Pemberton  
<steven.pemberton@cwi.nl> wrote:

> 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