W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

Re: Support for AVTs in XForms? [WAS: Dynamic @action attribute on xforms:submission]

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 25 Apr 2006 23:42:39 -0700
To: Erik Bruchez <ebruchez@orbeon.com>
Cc: www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFA0974567.53B0351F-ON8825715C.0023B4E6-8825715C.0024DD2F@ca.ibm.com>
Someone on this thread attributed to me the following:

>>John mentions that it "keeps coming up over and over and over again.", 

and then responded:

>> and I think there is a reason. People want to use it...

That person misinterpreted the word "it".  By "it", I meant that dynamic 
action attribute comes up over and over again.
*Then* the discussion of AVTs comes up. 
**Then** we remember why AVTs are a Pandora's box.
***Then*** we discuss using event context. 
****Then**** we forget we had the discussion.

AVTs are so tempting to provide the point solution to this one problem. 
But then we would confuse people with our
language because they start wondering why they can't use it in the control 
attribute of setfocus, then the case
attribute of toggle.  Then, they wonder why we can use it anywhere and 
everywhere.  I really don't think that a 
one line event handler to reset the action of a submission involves very 
much voodoo deep understanding
of cryptic XML events, but I especially don't think it is as hard as 
trying to explain what is supposed to happen
when someone uses an AVT in the nodeset or calculate attribute of a bind, 
or in a UI binding attribute.

This not to mention the fact that the same folks start wondering why AVT 
usage isn't allowed in the host language, 
an issue that is especially pertinent for  XHTML because it is importing 
the XForms tag set into *its own namespace*.

This is a serious scope containment issue.  It looks like a beautiful 
solution by itself, but it doesn't even solve all the
problems we have discussed (e.g. content header rewriting), and it 
introduces an endless plethora of other unsolved 
problems.   By comparison, rewriting the action in an event handler is 
already consistent with machinery we're
putting into 1.1, like overloading the serialization on 
xforms-submit-serialize.  Why not solve the problem in a manner
consistent with how we are solving other problems related to overloading 
how submission operates?

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-request@w3.org
04/25/2006 06:00 PM


Re: Support for AVTs in XForms? [WAS: Dynamic @action attribute on 

Joern Turner wrote:

> Why not use multiple setvalue action in this case? IMO this would be 
> much clearer cause normally setvalue specifies exactly one value.

My point was that you must specify:

1. That you are setting a header (vs. an action, or something else).

2. The name of the header.

3. The value of the header.

This is different from just setting the value for the action: there is 
one more parameter, which is the name of the header.

> While i absolutely agree on the usefulness of such a construct i also 
> see problems here:
> it just doesn't feel right to allow XForms as an embedded language to 
> change attributes of its host language. While this might work with HTML 
> (i actually can't find an example where this would cause problems) you 
> can imagine that it could cause trouble for some other host language.

Maybe this can be up to the XForms / host language integration to 
specify this. I don't think it would necessarily make sense for XForms 
in general to specify that every host language must support AVTs. But 
since it makes so much sense for (X)HTML, some serious thinking should 
be done in this case.


Orbeon - XForms Everywhere:
Received on Wednesday, 26 April 2006 06:42:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC