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

Hi Uli,

I think you misread rule 43.

It does allow empty content.  Of course it must, as it is *the* definition 
of element content in XML, and an element may have no content.

Look closely and you will see that the first CharData has a question mark 
after it, so it is optional.  The second piece of the rule is the entire 
rest of it, which has a star, again meaning you may have zero of them.

That being said, I do agree with you that language based on XPath string() 
should *also* appear.

I was thinking that we would say that the binding to an element allows 
manipulation of the elements content.  The string() of the content would 
be presented by a control, but we have to use the more basic XML notion of 
content to get at the setter side of UI binding and the setvalue action 
because there is no notion of mutation in the XPath data model.  We 
couldn't say that we replace the string() of the element with the new... 
content.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Ulrich Nicolas Lissé <unl@dreamlab.net> 
06/20/2007 01:42 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
ebruchez@orbeon.com, public-forms@w3.org
Subject
Re: test case for bind/@type validation and first text node rule






John,

in the telecon today we agreed that it is a good thing to drop the first
text node rule for getting/setting instance data values. You proposed we
use the definition of content found in
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags Rule 43.
However, the rule is

content          ::= CharData? ((element | Reference | CDSect | PI | 
Comment)
CharData?)*

which means to me: There is no emtpy content. So we would still suffer
from the idiosyncrasy that binding to an empty element would make a
control non-relevant because there is no content.

I like the idea of using XML's content definition, but it won't solve
all problems we have with the first text node rule. So maybe we should
stick to the XPath Data Model: In http://www.w3.org/TR/xpath#data-model
there is string-value language. For empty Elements string-value would
turn out to be the empty string. This would keep the controls from
becoming non-relevant in the first place.

Regards,
Uli.

John Boyer wrote:
> 
> Hi Erik,
> 
> I wasn't writing spec ready text, but the idea is pretty close.
> 
> We bind to the node, and manipulate its *content*.  That works even for
> non-elements.
> 
> It also works across our definitions of type and UI bindings.
> 
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com 
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 
> 
> 
> 
> *Erik Bruchez <ebruchez@orbeon.com>*
> Sent by: public-forms-request@w3.org
> 
> 06/19/2007 01:07 PM
> Please respond to
> ebruchez@orbeon.com
> 
> 
> 
> To
>                public-forms@w3.org
> cc
>                public-forms@w3.org
> Subject
>                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/
> 
> 
> 


-- 
Ulrich Nicolas Lissé