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é

Received on Wednesday, 20 June 2007 20:42:19 UTC