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

Received on Wednesday, 26 April 2006 10:36:17 UTC