- From: Erik Bruchez <erik@bruchez.org>
- Date: Wed, 2 May 2012 09:13:23 -0700
- To: public-forms@w3.org
All, As per our discussion today, I have added this note to the wiki spec: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#Implementation_Requirements_Common_to_All_Form_Controls (I wanted the "Note" text to be aligned under the bullet list, but I am not sure there is a way to do that and the text of the note appears a bit more indented.) This completes ACTION-1900 - Add the note from the email to the ui-processing section in the XForms 2.0 wiki spec. -Erik On Wed, Apr 25, 2012 at 9:14 AM, Erik Bruchez <erik@bruchez.org> wrote: > John, > > Thanks for your comments. So in short: > > - the spec allows binding to text nodes > - that is however not an intended use case for XForms, and likely > produces funny results > - an author has to go a bit out of their way anyway to do this, using text() > - the spec does not prevent implementations to support binding to > comment or PI nodes > - binding exceptions are limited to document nodes and complex content > as that is in line with Schema > > Assuming I am correct above, I think that is fine, and I don't propose > changing that behavior. > > During today's call I suggested adding a short note to help > implementors like us. [1] So what about adding this clarification, in > the bullet point starting with "All form controls that read > simpleContent instance data must do so as follows:": > > "Note: > > The simpleContent binding restriction is intended to allow controls to > bind to attribute and element nodes. This specification does not > prevent binding controls directly to text nodes, however doing so can > yield undesirable behavior, such as controls becoming non-relevant as > soon as the user enters data. This specification also does not prevent > implementors supporting binding controls directly to comment or > processing instruction nodes, however the resulting behavior is > implementation-dependent and may also yield undesirable behavior." > > Any thoughts on this? > > -Erik > > [1] ACTION-1898 - Write spec note clarifying bind to text nodes > > On Tue, Apr 24, 2012 at 2:57 PM, John Boyer <boyerj@ca.ibm.com> wrote: >> Hi Erik, >> >> Not sure how well minuted it is, but this has been discussed somewhere in >> the yawning cavern of the WG history. >> >> The net of the discussion is that there was not a lot of reason to do any >> further fine-tuning of the spec for this issue. >> >> The xpath data model (XDM), which is normatively referenced, doesn't allow >> empty text nodes, so it is already clear to the implementer, who is the >> primary audience of the spec. Moreover, a form author has to go out of >> their way to write an xpath that gives them the less desirable behavior of a >> disappearing input control. To expand your foobar example just a bit, >> supposing you had: >> >> <xf:instance> >> <person> >> <name>Erik</name> >> </person> >> </xf:instance> >> >> Then the typical form author would be much more inclined to write >> >> <xf:input ref="name"> ... >> >> rather than >> >> <xf:input ref="name/text()">... >> >> particularly when the form author quickly discovers that the latter has some >> undesirable side effects, including the one around empty strings, that are >> so easily remedied by using the former. >> >> FWIW, the discussion was a bit more involved, covering the conclusion that >> XForms is an XML data collection application, not really a general XML >> editing application, so there are indeed a few issues that affect the latter >> but aren't really worth calling out. For example, not only can an XPath >> address the text node, it can also address, say, the second text node child >> of an element, which may be separated from the first by a PI or comment. In >> fact, one can even address the PIs and comments. Technically, this stuff >> could work, but XForms does little to help a form author reasonably deal >> with this use case because it is not in line with the type of application >> that XForms is. >> >> In this way, we drew the line at roughly the same place where XML schema >> did, i.e. they don't really pay much attention to whether character content >> being validated comes from one text node or several text nodes with >> intervening PIs or comments. >> >> Then, later, there was some emphasis placed on the data binding restrictions >> because implementers needed to know when to issue a binding exception, and >> the language from XML schema was used due to the affinity between XML schema >> as validator of XML data and XForms as collector of XML data. I don't think >> there was any explicit consideration given to whether those binding >> restrictions would or would not cause a problem for binding directly to a >> text node, but that's probably because binding directly to a text node is >> not really a use case for XForms, even though XPath can technically do it. >> >> 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 >> >> Twitter: http://twitter.com/johnboyerphd >> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer >> Blog RSS feed: >> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw >> >> >> >> >> >> From: Erik Bruchez <ebruchez@orbeon.com> >> To: public-forms@w3.org >> Date: 23/04/2012 04:57 PM >> Subject: Binding to text nodes >> Sent by: ebruchez@gmail.com >> ________________________________ >> >> >> >> All, >> >> I could swear that we had covered this a long time ago, but I can't >> find something very clear in XForms 1.1 on this. >> >> The scenario is the following: >> >> <xf:instance> >> <foo>bar</foo> >> </xf:instance> >> >> <xf:input ref="text()"> >> >> If this is allowed, upon initialization, <xf:input> binds to the text >> node, and reads "the string-value of the node" [1]. But if the user >> changes the value to the empty string, then as per setvalue, "the text >> node is eliminated if the new value is the empty string" [2]. This >> means the control loses its binding at the next refresh. >> >> But do we actually disallow it, or warn about it? I can't find whether >> that's the case. >> >> Controls like <xf:input> have a "data binding restriction", which says >> that they must bind to "simpleContent". What's not clear to me is >> whether this term, which comes from XML Schema, encompasses binding to >> text nodes. As usual deciphering XML Schema is difficult! >> >> In short, I am asking: >> >> - whether we made a decision on whether binding <xf:input> etc. to >> text nodes is allowed >> - if not, we should make such a decision >> - if we decide(d) against allowing such bindings, we should make the >> spec clearer >> - if we decide(d) for allowing such bindings, we should make the spec >> clearer and warn of the scenario above >> >> Thanks, >> >> -Erik >> >> [1] http://www.w3.org/TR/xforms11/#ui-processing >> [2] http://www.w3.org/TR/xforms11/#action-setvalue >> >>
Received on Wednesday, 2 May 2012 16:14:18 UTC