Add whitespace trim form field member

[lhazlewood]

A certain class of errors surface when a form field string value has leading or trailing whitespace (or both) or is the empty string. It would be ideal if the spec allowed content authors to eliminate these problems and even take a default position to do so.

This issue is a proposal to add a form field member named trim that is a string that may have one of 5 possible values: leading, trailing both, tonull and none with the following semantics:

• leading: remove any leading whitespace in the field value before further evaluation
• trailing: remove any trailing whitespace in the field value before further evaluation
• both: remove any leading and trailing whitespace in the field value before further evaluation.
• tonull: remove any leading and trailing whitespace. If the resulting string is the empty string, replace the value with null.
• none: don't modify the field value string at all before further evaluation.

This field MUST be evaluated before evaluating the value against any potentially specified pattern field.

This field would only be evaluated if the field type is string or a string derivative type (like date, time, duration, etc).

If the field type is string (or a derived string type), and a trim member is not defined, then Ion parsers MUST assume a behavior of trim equal to tonull. This default is chosen as it is assumed that the majority of data processing systems do not want any leading or trailing white space or the empty string for data.

Is this a welcome addition? A negative one? Thoughts and opinions welcome.

cc @dogeared @nbarbettini @niklase @fosrias @smizell

[nbarbettini]

Interesting. I could see tonull being useful to be more explicit about how empty strings should behave.

To play devil's advocate: why should this be the concern of ION?

[niklase]

I suppose the field MUST be evaluated before maxlength and minlength too? And if any other string validations will be introduced in the future they will always be applied after trim.

What about options?

"When an options member is present and the form field type does not equal set or array, any form field value specified MUST equal one of the values found within the Option array." - the value should equal the option after trim had been applied?

I agree trim can be useful and it would be good if it can be expressed in some kind of validation lifecycle/process where all rules to be performed on a string value should be applied after the trim has been applied.