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

Hi David,

The problem is not whether you can do a quick one-off hack of an AVT for 
one attribute.
The problem is that someone (any volunteers?) needs to work out what does 
it mean to add "Attribute value templates" to a language like XForms.

The very point you mention about there being a problem using an AVT in our 
src attribute is an excellent example.
But why not type?

What about @bind, @nodeset, @ref, @value?

And so on...

As posted in another email, we have not even really even decided as a 
group that AVTs will get added to XForms, 
so chucking one in now as an easy way to get one requirement solved is 
problematic because it then obligates
us to expand AVT support later, as opposed to having an option to avoid 
AVTs altogether should that be the
conclusion we draw from a full analysis of the implications of the 
addition.

Since we have another easy solution for 1.1 whose scope is easily seen to 
be constrained to the specific 1.1 requirement
we are trying to address, it seems better to focus on writing up that 
solution so that we can deliver 1.1 faster.
Then, we could actually get on to XForms 2.0 faster...

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





David Landwehr <david.landwehr@solidapp.com> 
Sent by: www-forms-request@w3.org
04/26/2006 03:36 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
Erik Bruchez <ebruchez@orbeon.com>, www-forms@w3.org, 
www-forms-request@w3.org
Subject
Re: Support for AVTs in XForms? [WAS: Dynamic @action attribute on 
xforms:submission]







To me it is strange that the working group has problems coming to a 
conclusion on this since several implementors have AVT functionality. It 
would be nice to understand what exactly the problem is. E.g. I made 
some choices for which attributes could have AVT in my implementation as 
I did not want to support it for attributes like @src, any attributes 
containing XPath expressions, the @type attribute on bind and so on and 
so on. I don't even support AVT on the host markup... The choices I 
made, made it easy for me to implement and still provides useful 
functionality. XSLT made similar choices for which attributes they allow 
AVT (in the XSLT language that is).

Best regards,
David

John Boyer wrote:
>
> 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
>
> 
> To
>                www-forms@w3.org
> cc
> 
> Subject
>                Re: Support for AVTs in XForms? [WAS: Dynamic @action 
attribute on 
>  xforms:submission]
>
>
>
> 
>
>
>
>
>
>
> 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.
>
> -Erik
>
> -- 
> Orbeon - XForms Everywhere:
> http://www.orbeon.com/blog/
>
>


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------