Re: @ref vs @nodeset

Hi Erik and Nick,

I also see only benefits in the simplification proposal, except that it is 
entirely but only appropriate for local attributes, not global attributes 
in the XForms namespace.  I thought this was pretty clear in my last 
email, but you guys skipped it, so I'll try again.

In Nick's preceding mail, he makes the point that the form author should 
not have to think much about the kind of binding needed, and I agree with 
that too.  But again, the rationale is entirely but only appropriate for 
local attributes, not global attributes in the XForms namespace.

An XForms processor cannot possibly know what kind of binding a custom 
control will want.  So, everything you propose is appropriate for the ref 
and bind attributes, but not for xforms:ref and xforms:bind. 

One way to solve the problem is to go forward with the simplification, 
deprecate nodeset attribute, ***and either*** 

1) deprecate xforms:ref and xforms:bind (which ODF currently uses) and 
instead advise consumer host language designers that they must import @ref 
and @bind into their own namespace and define what kind of binding it 
creates (this is what Nick proposes)

***or ***

2) define a specific meaning for xforms:ref and xforms:bind corresponding 
to the most probable use, which would likely be a single-node UI binding, 
and possibly include some kind of extra attribute to control aspects of 
binding.

Either solution seems to work *for the global attributes*.  Can you guys 
give some further thought to the specific issue of the meaning of a global 
attribute in the XForms namespace? 

Finally, Erik, I don't think your opening question about @bind has 
anything to do with the problem I am trying to get you to think about, 
which is the expected behavior of *global attributes* versus local 
attributes. 

Your point is that "we already have a problem distinguishing between the 
ref semantic versus the nodeset semantic due to the use of @bind, i.e. we 
already have to automatically distinguish between single node UI binding 
and nodeset UI binding when @bind is used, so the ref vs. nodeset 
distinction is artificial."  I get it.  Agreed.  Peace. Much love.  Two 
fist bumps to my chest.

In fact, the first part of my prior email *magnified* your point here. Not 
only must we distinguish between the "first node rule"+"UI events and 
MIPs" behavior of a ref vs. the absence of those two properties on a 
nodeset, but we also must distinguish nodeset as template repeater vs. 
nodeset as a simple nodeset, and we must also already automatically 
distinguish ref as single node UI binding vs. ref as a simple first node 
XPath.  And, by implication, these distinctions are also automatically 
being made when the form author uses the bind attribute.

So, the net is that an XForms 1.1 processor does quite a bit of work 
distinguishing which of *multiple* features to activate for a binding 
when... a *local* binding attribute is used.  The XForms processor can 
afford to *automatically* make this distinction because the XForms *owns 
the definition of the containing element*.  XForms does not own the 
definition of a custom foreign-namespaced element, so an XForms processor 
cannot offer a globally namespaced xforms:bind or xforms:ref attribute 
whose behavior automatically adapts to the properties of foreign 
namespaced elements that the XForms processor doesn't know anything about.

On the other hand, the processor for the foreign namespaced element is 
perfectly capable of reading its own *local* attribute and assigning to it 
a specific kind of XForms binding that it creates by calling *APIs* of the 
XForms processor (the existence of which would be at least implied by the 
binding definitions in the XForms specification, even if an exact IDL 
interface definition were not provided).  Heck, they wouldn't even have to 
call the attributes ref or bind, though we could recommend they do.

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:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
03/18/2010 01:17 AM
Subject:
Re: @ref vs @nodeset



John,

What about @bind then? Simply looking at the @bind attribute, you can't 
tell whether the consumer of the attribute will apply a single-node rule 
or consume the whole node-set. I argued in my message on @ref vs. @nodeset 
[1] that we wouldn't be doing anything different by standardizing on @ref.

In the case of languages importing XForms attributes on their own 
elements, like <my:e> below, the language will have to determine 
what <my:e> is: is it a control acting like an xf:input? If so, the 
control will consume only the first node of the binding. Is it a control 
acting more like xf:repeat? Then it can consume the whole node-set. In 
short, I don't quite see why the attribute should absolutely specify that 
aspect of things (especially since @bind seems to work just fine).

The rules for @ref would be simple:

* @ref returns whatever its XPath expression returns
* if the control supports single-node binding, it consumes the first node 
only (if any)
* if the control supports a node-set binding (only repeat so far, since 
itemset if not a control proper) it consumes the entire node-set
* MIP events are handled by the control according to the rules we are 
defining for the improved UI events
* a node-set would not imply repetition (I don't think a good case has 
been made for this and we already repeat element/attribute)

So far I still see only benefits to this proposed simplification:

* It doesn't make life more difficult to implementors since they already 
must support @bind.
* It removes (deprecates) one attribute from the plethora of XForms 
attributes.
* It solves the case of authors trying to use xforms:bind/@ref.

-Erik

[1] http://lists.w3.org/Archives/Public/public-forms/2010Mar/0003.html

2010/3/17 John Boyer <boyerj@ca.ibm.com>

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é