RE: @ref vs @nodeset

Hi John and group,

I think (and if I read it correctly that is what Erik and Uli are thinking too) that there is a difference in what the 'author of a form' has to do to setup a data binding on a control, with other words the consumer of the control, and the 'creator/author' of the control (the XForms spec, a native XForms custom control or a 'custom' control defined by a 'host' language).

In my opinion the form author shouldn't have to know (and specify) if he needs a SNB that binds to the first text node (using ref), a node set (using nodeset), a sequence (using???), a SNB that binds to the complex content (using ???), ....

The 'creator/author' of the control should do the hard work on specifying how the control binds to data, it could even be determined by a custom attribute on the control (e.g.: a rich text area that binds to a single node but in one case the 'rich' content is represented as text() by default, but if you could also specify that it should bind to the subtree and treat the markup as real xml nodes). Therefore I think that the 'creator/author' of a custom XForms control should specify the type of the binding (not the consumer of the control, i.e. the form author). Additionally I think we should consider 'if we want to create an interoperable means of how other 'host' languages could express what kind of data binding they want' for their native controls. A possible solution could be that the host language has to specify how the control can be implicitly mapped to native XForms controls using our custom control syntax.

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: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: woensdag 17 maart 2010 19:46
To: Ulrich Nicolas Lissé
Cc: Forms WG
Subject: 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é



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