RE: @ref vs @nodeset

Hi John,

Thank you for your detailed response.

Currently I think that a host language should be free to choose if he wants to use local or global versions of our @ref (or @??? attribute that contains an XPath expression) and @bind. I think the host language should be able to choose another name for the @ref attribute; it should even be possible to have multiple data binding attributes on a UI control.

The host language needs some 'code' to consume the data and render the UI control (also consuming validity, required and read-only info). The 'code' could be as simple specifying the custom control in XForms specific markup, but I don't think this should be the only way (the XForms native UI controls are also created in a host language/'browser' specific manner). In my opinion specifying what the binding attributes do is also specified at this layer (and is abstracted away from the Form author layer).

One possible solution is to introduce a new attribute @select (better names are welcome) which is used at the Form author layer, together with @bind (a control could even choose to use another name for a insuring a more natural integration with the host language).  And use @ref / @nodeset and @bind-ref / @bind-nodeset (better names are welcome) at the form control definition layer, when defining (custom) controls explicitly or implicitly. All attributes could be used globally too, but the @xforms:select and @xforms:bind should be explicitly or implicitly be allowed and given a meaning (at the form control definition layer).

All comments are as always welcome, I think we are making progress on this.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: John Boyer [mailto:boyerj@ca.ibm.com]
Sent: donderdag 18 maart 2010 19:12
To: Erik Bruchez; Nick Van den Bleeken
Cc: Forms WG
Subject: 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<mailto: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<mailto: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<mailto:unl@dreamlab.net>>

To:

Forms WG <public-forms@w3.org<mailto: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é





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

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

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