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

Re: Binding to text nodes

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 24 Apr 2012 14:57:56 -0700
To: Erik Bruchez <ebruchez@orbeon.com>
Cc: ebruchez@gmail.com, public-forms@w3.org
Message-ID: <OFC2139731.C560FEB8-ON882579EA.00754C89-882579EA.0078AAC6@ca.ibm.com>
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 Tuesday, 24 April 2012 21:58:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:57 UTC