- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 16 Feb 2016 09:45:57 -0800
- To: Alain Couthures <alain.couthures@agencexml.com>
- Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Alain, > It remains me that XForms considers xsd:string for input/password controls while only xsd:normalizedString (no tab, no newline,...) is effectively supported Good point. And practically, as I was trying to make the case, it's even more strict than xsd:normalizedString for most practical application, since you want leading/trailing space trimming in most cases. > Do you mean, for example, that, in incremental mode, the input value for the > XForms control is always empty while the corresponding input field still > contains just spaces? Is the input field just updated to the XForms value > when focus is lost? I haven't thought much about incremental mode but as things stand, any update in the field in incremental mode would cause the model to update soon thereafter, and so whitespace processing would take place, and so the field would update back correspondingly (with trimmed spaces). This might be a problem in some cases, and so you might not want to enable whitespace trimming processing with an incremental field and instead trim after the user tabs out. > I think we should define a specific XForms data type for this case. This > type could then be bound to nodes or defined as default. Would the type cause trimming automatically, and if so at what point in the processing model? > We should always have a way to alter global engine options within a form. > XSLTForms v1 allows authors to add processing instructions for that purpose. > XSLTForms v2, because of HTML5, allows an <xforms-engine> element with > attributes. Attributes such as model/version and model/functions sound to me > more global options than options related to a specific model. I agree on this (global vs. model). Not sure about how to do it best. -Erik > > What do you think? > > --Alain > > > Le 11/02/2016 23:13, Erik Bruchez a écrit : >> >> All, >> >> We recently implemented an extension to do whitespace processing. I >> think this might be of interest to XForms implementers. Blog post: >> >> >> http://blog.orbeon.com/2016/02/required-fields-more-subtle-than-you.html >> >> Doc: >> >> http://doc.orbeon.com/xforms/binds.html#whitespace-processing >> >> -Erik >> >> >
Received on Tuesday, 16 February 2016 17:46:46 UTC