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

Re: Binding to text nodes

From: Erik Bruchez <erik@bruchez.org>
Date: Wed, 2 May 2012 15:42:43 -0700
Message-ID: <CAAc0PEVEkvs9yL04ar92-4DSVZK3FzcZ_77SgrBNnJjBRJvBsw@mail.gmail.com>
To: John Boyer <boyerj@ca.ibm.com>
Cc: public-forms@w3.org
Sounds good, thanks.

-Erik

On Wed, May 2, 2012 at 10:09 AM, John Boyer <boyerj@ca.ibm.com> wrote:
> 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
>>>
>>>
>
>
Received on Wednesday, 2 May 2012 22:43:34 UTC

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