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

All,

We had a follow-up to this conversation during today's call, on
whether one should be able to mutate nodes returned by element() and
attribute() or not. So we have a "mutable" and an "immutable" option.

Nick has some concerns about the "mutable" option (I hope I reflect
this correctly below):

If the author writes:

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

If the user enters a value in the field, it will be written to that
transient element. Then during refresh, the element will (probably,
depending on the implementation) be recreated, and the value will be
cleared unexpectedly. This also means that there can be some
interoperability issues, depending on how refresh is implemented.

Personally I don't think this is a showstopper, because:

1. We have a similar situation with binding to text() nodes, and we
have decided that we should just tell authors not to do that. And if
they do, and get the unexpected behavior or non-interoperable
behavior, well, too bad.

2. Even if you make element() return a read-only node, there is not
much of a use case for <xforms:input ref="element('foo')">. It's not
the intent of those functions to allow binding controls to them. So
it's really an edge case.

On the other hand, there is a benefit to the "mutable" option, namely
that they allow use cases of building trees within actions:

<xforms:var name="new" value="element('foo')"/>
<xforms:insert ref="$new" origin="attribute('bar')"/>
<xforms:setvalue ref="$new/@bar" value="42"/>

(Now yes in that simple example above, you can also write it in a
single expression:

<xforms:var name="new" value="element('foo', attribute('bar', 42))"/>

but just imagine a more complex algorithm that you would like to write
with actions.)

In short I am leaning toward the "mutable" option.

If bindings and interoperability are considered an issue, we could do
something similar to what we did for the valid() function, and say
that element() and attribute() are not allowed in certain places. [1]

I think it makes sense to say (if we don't already) that xforms:bind
must point to instance data nodes.

Now that is not a perfect way to avoid issues, because in theory, some
implementation might let nodes created within an action escape the
scope of the action. And if they can, then somebody outside the action
might be able to bind controls to them. So I don't even think it is
absolutely necessary to restrict the use of the functions, besides
making sure we say that binds must point to instance data nodes.

In summary I would suggest we do the following:

1. element() and attribute() return mutable nodes
2a. restrict the field of use of the functions to actions
2b. OR just have a note saying "don't bind controls and stuff to nodes
returned by these functions or else!"

-Erik

[1] http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_valid.28.29_Function

On Thu, Apr 5, 2012 at 10:06 AM, Erik Bruchez <ebruchez@gmail.com> wrote:
>> 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.
>
>
> Just adding an example of what NOT to do with element() is probably enough.
>
> -Erik
>

Received on Wednesday, 9 May 2012 16:39:28 UTC