Use Cases

Here are use cases for converting values on the way into controls and on the way back out. A single proposal might unify them, or it may be that different mechanisms are necessary.

select lists that aren't space separated

select allows complexContent to be repeated for insertion. select on simpleContent requires space-separated values. Rather than introducing @separator="," or some more complicated attribute-value language, we should consider using a pair of XPath 2 expressions to convert the instance value space into a sequence of atomic values for the current value of the select, and a companion XPath 2 expression that converts the sequence of atomic values back into simpleContent for insertion into the instance. (We will likely want to limit this to XPath 2 in order to use sequences.)

select with complexContent that isn't just repeated elements

We may also find that complexContent can be handled, either using element and attribute constructors, or by expansion into XQuery or XSLT for conversions.

input and spaces

The credit card number with spaces is a constant source of irritation. A "sanitizer" filter on input could remove spaces from values before storing them in the instance. This converter is unidirectional.

input and non-ISO dates in the instance

Some instance data contains non-ISO dates. We have no way to associate a date control with non-ISO dates. A bidirectional version of bind/@calculate could allow the use of a date parser and date formatter to make one node be an updatable view of another, and input could bind to that node, with its type being xsd:dateTime (for example).

It may also be possible to do this same thing with attributes directly on a form control

Formatted number control

In some cases you want to format the number in the UI, but store it as decimal in your instance. The most common case is a thousand separator (user should be able to leave out the thousand separator, but after exiting the field the thousand separator should be added), but there are more exotic cases e.g. negative numbers by surrounding number with parentesis.

Currency input control

In some cases a currency symbol should be automatically added to the input control but it shouldn't go in the instance (in the instance the value is a decimal)

Issues

Control-based, model-based, or both?
Is converting to/from the instance data to the control really the same problem as converting to/from the instance data to the presentation; or are controls dependent on data types, and users dependent on presentation?

References

http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components/dialog-select Note the @separator ad-hoc formatting language for controlling the visual appearance of the closed dialog select.
http://wiki.orbeon.com/forms/doc/developer-guide/xforms-other-extensions#TOC-Default-formatting
https://github.com/orbeon/orbeon-forms/blob/master/src/java/org/orbeon/oxf/xforms/control/controls/XFormsInputControl.java#L51