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