Re: @ref vs @nodeset

Hi Uli (and group),

In XForms for the local attributes (the ones not qualified by namespace), 
we have taken the approach that the XForms processor knows what these are 
and implicitly knows what semantics to attach.

You're indicating that any external consumer of XForms binding attributes 
would similarly make their own definitions, which is possible.  You're 
also advocating that we avoid use of additional attributes that would 
indicate what kind of binding is needed, since in fact the consuming 
language could make its own definitions.  Our spec language needs to get a 
little bit better in terms of saying what aspects of an XForms processor 
*must* be available to a consumer without syntactic activation, but again 
it's possible.

However, the hurdle I am trying to get over, and I think I am not alone in 
perceiving this hurdle, is that this issue of the consumer language making 
the definition seems at odds with the normal meaning of *global* 
attributes (i.e. namespace qualified attributes).

To me the debate is not really about @ref vs. @nodeset but rather can we 
come up with an @ref that is analogous to @xforms:ref.  Maybe we can't.

In the language of my forms product, XFDL, we solved this problem by 
importing the actual XForms elements so that the elements "plug in" and do 
what they do.  So to me, boiling it down to just @ref works because I 
already have two different meanings for each of @ref and @nodeset 
depending on the elements to which they are attached.  For @ref, elements 
like xf:input get UI events and MIPs whereas  xf:setvalue doesn't.  For 
@nodeset, elements like xf:repeat and xf:bind repeat the content and 
therefore have processing implications on other operations like 
xf:setfocus, whereas for an element like xf:insert, the nodeset is just an 
xpath expression.  The point is that by importing all of XForms, I don't 
have the problem because I delegate it to XForms.

However, in other languages like ODF, the tendency has been to import our 
globally namespaced attributes onto the host language elements and the 
expectation is still that the XForms attributes will "plug in" and do what 
they do.

So *what* do they do?

When someone says <my:e xforms:ref="some/data"/>, what is the meaning of 
that?

If we say that the designer of the processor for the element <my:e> must 
define this, then the "ref" should be a local attribute of <my:e>, not a 
global attribute in the XForms namespace.

But as a global attribute in the XForms namespace, it is supposed to be 
XForms that defines the meaning of xforms:ref, so XForms has to define 
whether

1) the first node rule applies
2) if the first node rule applies, then also whether my:e receives UI 
events and MIPs
3) if the first node rule doesn't apply, then does a nodeset result imply 
automatic repetition of the content of my:e?

Maybe the answer is that we need only one locally namespaced binding 
attribute, @ref (or @bind), whereas we need a greater multitude of 
globally namespaced attributes.  The default xforms:ref and xforms:bind 
could create our current notion of single node binding, but then have some 
kind of global attribute override(s) to select or deselect the known 
features of binding described above.

John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Ulrich Nicolas Lissé <unl@dreamlab.net>
To:
Forms WG <public-forms@w3.org>
Date:
03/17/2010 12:38 AM
Subject:
@ref vs @nodeset



Dear Group,

I followed the previous discussions with great attention. Since I can't
attend neither today's telecon nor the F2F I'll try to condense my
opinion here.

I'm definitely a supporter of unifying @ref and @nodeset. It would
obviously make author's life easier. And I think it would make also
implementor's life easier. Here's why:

The distinction between single-node and nodeset bindings is a no-brainer
and should be handled by the control (as Erik pointed out in [1]). We
already have language in the Spec that says which binding capabilities a
control has (e.g. "Data Binding Restrictions: Binds to any
simpleContent..." for xf:input). It would be just consistent to expand
that language to include the first-node rule for single-node bindings.

Furthermore, I don't see any need to invent a new attribute specifying
the binding type. First, I'm strongly opposed to introduce new
attributes, because XForms is already complex enough and just adding
another one would make things even worse. Second, I think it would be
actually wrong to add an attribute specifying binding behaviour, because
it would appear to authors like they could change it's value. Binding
behaviour of a control is given by our Spec, not on the markup level.

In [2] Charlie raised a concern about extensions like <xhtml:p
@ref="..."/> leading to the interesting question of who is in charge of
the binding: the model or the control? I think it should be the control.
And I don't see so much problems with that approach, since it reminds me
on the Dependency Injection [3] programming style. Instead of requiring
the model to actively manage all dependent bindings and their
update/event cycles, the control registers with the model and says: Hey,
I'm a single-node binding control - please provide me with updates for
that certain binding. That would work particularly well for extension
elements.

IMHO we overloaded @ref/@nodeset semantics in the past. They specify at
least two orthogonal concepts: The binding type of control and a
communication channel for events. As we are approaching an overhaul of
UI events, we should sort that out.

I would like to propose to deprecate @nodeset in XForms 1.2, so that
either @ref or @nodeset can be used where @nodeset is required in XForms
1.1. That won't break any existing form. In XForms 2.0 we could drop
@nodeset, and even switch to @select if we want to.

Regards,
Uli.

[1] http://lists.w3.org/Archives/Public/public-forms/2010Mar/0003.html
[2]
http://lists.w3.org/Archives/Public/public-forms/2010Mar/att-0009/2010-03-10.html

[3] http://martinfowler.com/articles/injection.html
-- 
Ulrich Nicolas Lissé