- From: John Boyer <boyerj@ca.ibm.com>
- Date: Thu, 14 Apr 2011 10:08:02 -0700
- To: Alain Couthures <alain.couthures@agencexml.com>
- Cc: "www-forms@w3.org" <www-forms@w3.org>
- Message-ID: <OF27BDD729.80AF08AB-ON88257872.005CA5CA-88257872.005E1E48@ca.ibm.com>
Hi Alain, OK, so a few things. First, what I said about normalized string was confusing it with XPath normalize space, which collapses whitespace. Second, I see your point that now, with tabbed browsers, hitting Ctrl-Tab now switches tabs, whereas it used to insert a tab. However, I have a browser plugin implementatoin that does still allow Ctrl-Tab to be used to enter a tab. Not sure it is of much value to end-users, but there has not been a point in making a restriction to the normal behavior of the underlying control. Third, I still think that normalizedString would not be any different than just string because it does not restrict tabs, returns and linefeeds from the lexical space of the XML node. The value space replaces tabs, returns and linefeeds with spaces, but the lexical space allows them. Fourth, even if there were a difference, it would then be harder to use XForms because we set default datatypes at the data layer, and we cannot reasonably do that based on what UI controls are bound to the data. Suppose input had a binding restriction to normalizedString. If we bound it to a string, the default datatype, then an exception would occur unless someone used a type MIP to assign normalizedString to the data node. The alternative would be that we'd have to make normalizedString the default, but then a type MIP would have to be used to assign string to any node one intended to bind to a textarea. This would be a lot more work to obtain restrictions that the UI controls themselves implement. Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw From: Alain Couthures <alain.couthures@agencexml.com> To: John Boyer/CanWest/IBM@IBMCA Cc: "www-forms@w3.org" <www-forms@w3.org> Date: 04/14/2011 09:37 AM Subject: Re: normalizedString/input and string/textarea? Sent by: www-forms-request@w3.org Hi John, Do you mean that the tab character is allowed for xf:input? It doesn't seem possible for HTML input, am I wrong? Thanks! -Alain Le 14/04/2011 18:26, John Boyer a écrit : Hi Alain, xsd:string is the almost-right datatype, and so there has been no priority on doing better. normalizedString does stuff to a string that we would not want. The exact right datatype would be one pattern derived from string with the regex pattern [^\n] as the only thing input really says differently than textarea is single line input. Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw From: Alain Couthures <alain.couthures@agencexml.com> To: "www-forms@w3.org" <www-forms@w3.org> Date: 04/14/2011 09:03 AM Subject: normalizedString/input and string/textarea? Sent by: www-forms-request@w3.org Hello, I'm still perplex about the differences between core forms input controls. More specifically, if I want to edit an instance according to types, I would consider that xsd:string is not correct for xf:input but for xf:textarea. It is obvious that the carriage return, line feed and tab characters cannot be entered using xf:input but xf:textarea. So, why isn't xsd:normalizedString the default type for xf:input? Thank you very much for your answers! Alain Couthures <agenceXML> http://www.agencexml.com/xsltforms
Received on Thursday, 14 April 2011 17:08:37 UTC