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

Re: Binding to text nodes

From: Erik Bruchez <erik@bruchez.org>
Date: Wed, 25 Apr 2012 09:14:39 -0700
Message-ID: <CAAc0PEUpkz=yiUHFhNXUjWuSwTr2BiYZ2f_SLhjG1U5QeE2U4w@mail.gmail.com>
To: public-forms@w3.org

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:":


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?


[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, 25 April 2012 16:15:33 UTC

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