W3C home > Mailing lists > Public > public-forms@w3.org > May 2012

Re: Binding to text nodes

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 2 May 2012 10:09:24 -0700
To: Erik Bruchez <erik@bruchez.org>
Cc: ebruchez@gmail.com, public-forms@w3.org
Message-ID: <OF87AED478.A2B29672-ON882579F2.005E0D8D-882579F2.005E4015@ca.ibm.com>
Looks good Erik.
Since it was a "such as" example anyway, I tweaked the note to say that 
entering *empty* data might result in a control bound to a text node 
becoming non-relevant. 


From:   Erik Bruchez <erik@bruchez.org>
To:     public-forms@w3.org
Date:   02/05/2012 09:39 AM
Subject:        Re: Binding to text nodes
Sent by:        ebruchez@gmail.com


As per our discussion today, I have added this note to the wiki spec:


(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.


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 
> - 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 
>> the yawning cavern of the WG history.
>> The net of the discussion is that there was not a lot of reason to do 
>> further fine-tuning of the spec for this issue.
>> The xpath data model (XDM), which is normatively referenced, doesn't 
>> 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 
>> undesirable side effects, including the one around empty strings, that 
>> so easily remedied by using the former.
>> FWIW, the discussion was a bit more involved, covering the conclusion 
>> XForms is an XML data collection application, not really a general XML
>> editing application, so there are indeed a few issues that affect the 
>> but aren't really worth calling out.  For example, not only can an 
>> address the text node, it can also address, say, the second text node 
>> 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 
>> could work, but XForms does little to help a form author reasonably 
>> with this use case because it is not in line with the type of 
>> that XForms is.
>> In this way, we drew the line at roughly the same place where XML 
>> did, i.e. they don't really pay much attention to whether character 
>> 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 
>> because implementers needed to know when to issue a binding exception, 
>> the language from XML schema was used due to the affinity between XML 
>> as validator of XML data and XForms as collector of XML data.  I don't 
>> there was any explicit consideration given to whether those binding
>> restrictions would or would not cause a problem for binding directly to 
>> text node, but that's probably because binding directly to a text node 
>> not really a use case for XForms, even though XPath can technically do 
>> 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 17:11:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:07 UTC