Re: test case for bind/@type validation and first text node rule

John,

 > In the 2004 email, it asks whether the UI binding is to the element
 > or to the text node.  It was clear at the time that it was not the
 > element, since the element may have attributes and the form control
 > cannot set those too.
 >
 > But no alternative to *the* text node interpretation was proposed.
 > Now, after three more years of experience, it is clearer that there
 > is a much more preferrable alternative, which is to say that the UI
 > binding binds to the content of the element.
 >
 > This means that the "string()" of the node is shown as the initial
 > content, and a change to the content would replace the existing
 > content with the new text, which may destroy any intervening PIs,
 > comments etc.

I am a little confused about the terminology you use above. I think it
is confusing to say that the control or the binding no longer binds to
an element "but to its content" as you state above.

If I write:

   <xforms:input ref="@first-name">

or:

   <xforms:input ref="first-name/text()">

I am binding to an attribute vs. a text node. So for consistency
writing:

   <xforms:input ref="first-name">

should still be called "binding to an element" because the XPath
expression refers to an element. It also means that the MIPs set on
that *element* are taken into account.

The same goes with binds:

   <xforms:bind nodeset="first-name" type="xs:date"/>

The bind binds to an *element* because of the XPath. But how the @type
attribute validates the element depends on how we specify that
behavior.

 From there, of course, we specify how a control bound to an element
reads or write the element's content, or how the binding bound to an
element validates the content of the element. Doing so does not
require us to say that the control no longer binds to an element.

This is just a question of terminology, but an important one in my
opinion, and it seems to me that saying that a control "binds to the
content" of an element does not solve a problem and rather adds
confusion.

 > One reason this was not considered is that it was not well-known,
 > despite being in the recommendation, that UI controls which attempt to
 > bind to nodes with complex content are supposed to produce a binding
 > exception.  This means that we don't need the first text node rule to
 > resolve the problem of binding to complex content.

So does this mean that during the f2f it was decided that this
restriction still applies, i.e. that we should still prevent binding
controls to nodes with children elements?

If we did make that decision, then I agree (as I suggested earlier as
well) that the first text node rule does not make any sense anymore,
and that we can then have a consistent solution where we read and
write the whole text content of the element, and we validate the whole
text content of the element as well when using simple types / simple
content.

 > Since we can focus on the issue of intervening PIs and comments, the
 > reality is that if someone really wants to bind to a particular text
 > node and preserve sibling PIs and comments, there is a way to do
 > that with a better XPath, but that isn't really our *main* use case,
 > so it should not be the default behavior.  When a UI binding and
 > type MIP both indicate an element, they should be talking about the
 > same thing, which is the content.

Agreed.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 19 June 2007 20:08:07 UTC