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