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: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 25 Apr 2006 11:20:04 -0700
Message-ID: <444E6854.2080208@orbeon.com>
To: www-forms@w3.org

Allan Beaufour wrote:
> On 4/20/06, David Landwehr <david.landwehr@solidapp.com> wrote:
>> To me it sounds like there is a real push for AVT from implementors and
>> as long the attributes which can contain AVT values does not changed the
>> processing model then there is no problem in implementing it (e.g.
>> having AVT in the @model attribute or @ref/@bind is difficult to
>> implement where having it in dispatch/@name is easy).
> 
> I agree. John mentions that it "keeps coming up over and over and over
> again.", and I think there is a reason. People want to use it... I
> definately believe that we should investigate how to include AVT
> support in XForms -- or once and for all find a definitive reason for
> why we should not. It's not a foreign concept in "w3-land"...
> http://www.w3.org/TR/xslt#attribute-value-templates
> 
>>  From an authoring perspective I would *much* rather have AVT than
>> writing an setvalue event handler which can change the @action URL. IMO
>> AVT is the intuitive solution for this problem.
> 
> I agree 100%, but others might think exactly the same for the setvalue
> approach :) But if both camps can be satisfied, well why not? :)

I have to concur in favor of the use of AVTs, for the reasons already 
mentioned.

I do think the event-modification solution has merits. But with all due 
respect I think in fact that John's example below is, well, not the best 
example:

<xf:submission action="blah" ...>
     <xf:setvalue ev:event="xforms-submit" ref="event('action')" 
value="some/node/in/instance"/>
</xf:submission>

It is bad because we have here a case where a common and apparently 
trivial task requires a cryptic line of XML and a deep understanding of 
XML event processing from the form author, instead of the "intuitive" 
AVT solution. Simple tasks should be easy to accomplish.

This is not to say that modifying events, as a general mechanism, 
doesn't have value, on the contrary. For example, when you start adding 
a large number of properties, such as headers, etc., this may become the 
preferred solution.

Regarding setting headers, BTW, how would you go about using xf:setvalue 
to set multiple headers? Would you then pass a second argument to the 
event() function, e.g. event('header', 'Accept')?

Regarding AVTs in general, there are different types of attributes:

1. Attribute of XForms, like xf:submission/@action. One question to 
answer here is whether all such attributes support AVTs, and if not, 
which do.

2. Attributes of the host language, like xhtml:table/@colspan. In this 
case, it appears reasonable that all attributes would support AVTs. At 
least, in the case of HTML, all attributes under and including the 
xhtml:body element.

The first category addresses the question of attributes that are static 
but would benefit from being dynamic. The second category addresses the 
question of modifying attributes of host language elements. Both should 
be addressed IMO.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/
Received on Tuesday, 25 April 2006 18:23:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT