Re: Binding to text nodes

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. 

Cheers,
John




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



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