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

[Fwd: Re: filter thoughts] -repost (somethings up with my email today)

From: Jason <jeacott@hardlight.com.au>
Date: Mon, 06 Nov 2006 21:58:34 +1030
Message-ID: <454F1C62.2060203@hardlight.com.au>
To: www-forms <www-forms@w3.org>

yeh my implementation suggestion could use some work, I had thought
perhaps just a simple <filter> element/action handler as you say so that
chaining becomes simple to define, extra options are easier to include,
and readability is maintained.

Its nice to get some support :)

mark.birbeck@x-port.net wrote:
> Jason,
> I think this is a great idea, as I'm sure will many who read it.
> I had a slightly different take on how to add it to XForms though.
> There have been some additions to XForms lately to give the author
> access to data at various stages of processing--just before
> submission, after submission errors, and so on. So, the thing to do
> would be to allow an action handler that performs a transformation on
> On 06/11/06, Jason <jeacott@hardlight.com.au> wrote:
>> Hi all,
>>     just a thought, but is there any reason that in a submission element
>> there couldn't be attributes like:
>> outfilter="some-bind-or-embeddedxsltref or url"
>> infilter="some-bind-or-embeddedxsltref or url"
>> ?
>> or even outfilterchain=""!
>> it would make submission processing far more powerful and could provide
>> much simpler ways to reuse the same form for different datasets.
>> Wouldnt it solve a lot of the submission issues related to webservices
>> by enabling a subset of any instance data to be aquired or saved for/to
>> whatever format without re-tailoring an entire form with custom bits of
>> essentially hardcoded data. XSLT can be built smart to dynamically
>> assess the input XML and select its own appropriate output, so that
>> loading data from various different known sources becomes much simpler.
>> Imagine a single Xform that could load and submit from a whole variety
>> of search engines for example (obviously the search engines would need
>> to actually support XML output in order to facilitate loading of their
>> data in our form).
>> I find myself doing this kind of thing serverside all the time in order
>> to support my xforms anyway. I use it to ensure any missing elements and
>> attributes exist for my forms, and to transform data to/from various
>> formats including making nice human readable email submissions! Can
>> anyone else see value in supporting this directly in the form?
>> it doesn't even need to restrict itself to xslt - let the filter itself
>> define its own language, xslt, javascript, anything.
>> perhaps this is already possible with events and xslt in the container
>> doc? not sure about that.
>> any thoughts?
>> Jason.
Received on Monday, 6 November 2006 11:30:15 UTC

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