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

John,

John Boyer wrote:
> 
> 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.
> 

how embarassing. Of course you are right. I must have been blind.

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

Sounds completely right to me.

Uli.

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


-- 
Ulrich Nicolas Lissé

Received on Saturday, 23 June 2007 20:46:50 UTC