Re: XPath 2.0: on bindings to atomic values and the result of the element()/attribute() functions

4. Summary

Here is what I think needs to be done:

- The working group must confirm that there is no restriction on
control bindings
+1
- The spec must be explicit about this and provide examples
+1
- The working group must decide what you can do with the result of the
element() and attribute() functions. In particular, can you insert or
setvalue into the resulting nodes? If so, my vote would go to make
those nodes read-write.
This one is a bit more difficult, I see the use case of using insert or setvalue on the resulting nodes, but I also see users not understanding why there values in controls are reset on 'arbitrary' moments in time (in fact it will be when the function is re-evaluated, but this might not be on every refresh in some implementations).

After some more thought I'm no longer strongly against making the resulting nodes of the element() and attribute() functions read/write. But if we make the resulting nodes read/write, we should at least add a note in the spec to warn implementers for this behavior. Maybe even encourage implementers to 'log a warning' if a form control is bound to a resulting node or a descendant of it.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 04 Apr 2012, at 18:47, Erik Bruchez wrote:

All,

In today's weekly call, following up on the thread started by Alain
[1], we discussed some questions and issues associated with bindings
with @ref to items other than instance data nodes.

1. Introduction

XPath 2 clearly can return items other than nodes, namely atomic
values. So you could write:

   <xforms:input ref="1">

or:

   <xforms:repeat ref="foo/bar, 42, gaga">

Also, XForms 2 adds new element and attribute creation functions [2].
So you can write:

   <xforms:input ref="element('foo')">

Now the question is: what does XForms say about that kind of
situations? As Nick mentions, the spec doesn't currently restrict
bindings on controls, but I think we must go a little beyond "not
restricting": the spec must make it clear that those scenarios are
allowed, and provide examples.

Below I show some use cases and list a few open questions.

2. Use cases for binding to atomic values (or a mix of atomic values
and instance data nodes)

In particular for repeat, this allows you to implement repeating
content a number of time, for example:

   <xforms:repeat ref="$min to $max">

or:

   <xforms:repeat ref="'cat', 'dog', 'fish'">
       <xforms:output value="."/>
   </xforms:repeat>

The same goes for itemsets.

Note that in the case of repeat, processing of repeat iterations can
(or even must) be "smart" in the way XForms 1.1 already suggests for
repeating over nodesets. If you have:

   <xforms:var name="max" value="..."/>
   <xforms:repeat ref="1 to $max">

and $max changes from 2 to 3 between refreshes, the repeat can nicely
just add the new iteration. This is what we do in our implementation.

Note also that for controls that can write values through their
binding, such as in:

   <xforms:input ref="1">

we simply say that atomic values are readonly. Problem solved. It's
all easy and consistent.

The working group discussed all of this in the past, but might have
stopped short of an actual resolution. Obviously I think that this is
a definite "go" and must be clarified in the spec.

3. Binding to the result of the element() or attribute()  function

Nick mentioned that the working group had suggested in the past that
nodes that are not instance data nodes should behave as readonly nodes
from the point of view of bindings. So in this example, the input
control would then be marked as readonly:

   <xforms:input ref="element('foo')">

Here I have some doubts about making the node readonly this is
absolutely needed. Consider the following example.

   <action>
       <var name="elem" value="element('foo')"/>
       <insert context="$elem" origin="element('bar')"/>
       <insert context="instance()" origin="$elem"/>
   </action>

In this example, I am creating an element, and keeping the reference
in a variable, then inserting new content into that element with the
insert action. This works unless we explicitly say that the result of
the element() function is immutable (and at this time the spec doesn't
say that this must be the case).

In our implementation, the result of the element() function is a
mutable element node, so the above code works.

Now if the node is mutable I don't see a rationale for marking the
node as readonly. Certainly, binding to the result of the element()
wouldn't be very wise to do, as during refresh there is a good
likelihood, depending on the implementation, that the node will be
recreated, and so any value stored by the control would disappear. But
then that would be the form author's problem.

4. Summary

Here is what I think needs to be done:

- The working group must confirm that there is no restriction on
control bindings
- The spec must be explicit about this and provide examples
- The working group must decide what you can do with the result of the
element() and attribute() functions. In particular, can you insert or
setvalue into the resulting nodes? If so, my vote would go to make
those nodes read-write.

Feedback welcome.

-Erik

[1] http://lists.w3.org/Archives/Public/public-xformsusers/2012Apr/0000.html
[2] https://www.w3.org/MarkUp/Forms/Group/Drafts/WD-xforms-xpath-20120504/#The_element.28.29_Function


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer