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: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Fri, 28 Apr 2006 11:26:11 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF401C4ED4B@usa7061ms01.na.xerox.net>
To: <www-forms@w3.org>
Cc: "Klotz, Leigh" <Leigh.Klotz@xerox.com>

Pardon me for not having tracked this, but wasn't there an idea in the
past for having child elements of submission bound to nodes to control

Then you can use almost any of the mechanisms proposed to set the data
and then use single-node binding to set the headers.
   <submission id="foo">
       <header name="User-Agent">Foo v1.12</header>
   <submission id="foo">
     <action ev:event="xforms-submit"><setvalue
ref="instance('data')/agent">Foo v1.12</setvalue></action>
       <header name="User-Agent" ref="instance('data')/agent" />
   <submission id="foo">
       <header name="User-Agent" value="concat(instance('data')/agent, '
', instance('data')/versionnumber)" />
   <submission id="foo">
       <header name="User-Agent" value="${a}${b}" /> <!-- or whatever
the AVL syntax works out to -->

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Erik Bruchez
Sent: Tuesday, April 25, 2006 11:20 AM
To: www-forms@w3.org
Subject: Re: Support for AVTs in XForms? [WAS: Dynamic @action attribute
on xforms:submission]

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

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

<xf:submission action="blah" ...>
     <xf:setvalue ev:event="xforms-submit" ref="event('action')" 

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.


Orbeon - XForms Everywhere:
Received on Friday, 28 April 2006 18:27:14 UTC

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