Question

As a reference, the most similar question already asked is: https://stackoverflow.com/questions/8667849/making-xforms-enforce-the-constraint-and-type-model-item-properties-only-when-fi The difference is that I cannot use the ‘relevant’ property since I do want the field to be visible and accessible.

I’m attempting to make an XForms form that has the following properties:

1. It displays a text field named ‘information’. (for the example)
2. This field must not be required, since it may not be necessary to enter data. (Or this data will be entered at a later time.)
3. However, if data is entered in this field, it must adhere to the specified constraint.
4. I cannot mark the field as not relevant since this would hide the field and some data may need to be entered in it.

The trouble now is that even though the field has no data in it, the constraint is still enforced (i.e. even though it is not marked as ‘required’).

I have taken a look at the XForms 1.1 specification, however it does not seem to describe how the properties ‘required’ and ‘constraint’ should interact.

The only option I see, is to add a part to the constraint such that an empty value is allowed.
e.g.:

. = ” or <actual-constraint>

However, I don’t like this. It feels like a workaround to add this to every such field.

Is there any other way to express that non-required fields should not need to match the constraint for that field? (Am I missing something?)

Answer 1

In XForms 1.1, required serves two purposes:

1. mark the field as required (implementations can style controls to reflect this, e.g. with a “*”)
2. take part in the validation process

The latter is described in 4.3.3 The xforms-revalidate Event.

An instance node is valid if and only if the following conditions hold:

And one of the conditions is:

the value is non-empty if the required model item property is true

So it is a logical and between all aspects that impact validation.

I can see how things could have been different, e.g. saying required="false()" could disable the rest of the validation. However that’s not the approach XForms is taking.

Based on this there is nothing wrong checking for emptiness as part of the constraint.

XForms 2.0 might add custom XPath functions, which might help with reuse of logic:

<bind ref="information" constraint="my:constraint(.)">

Also, if the constraint can be expressed with a type, you may be able to use one of the schema types in the XForms namespace, which allow empty values to be valid. For instance xforms:double considered the empty string and 42 to be valid values, but not gaga.