Re: Deploying (accessible) XForms today?

Eric, No, it's not about declarative/imperative religion.

When you have a prescriptive processing model, it defines a fine
number of transition points/hooks for adaptive technology to
watch and appropriately respond to the user.

when you have an open ended program in a turing complete
language, you also end up with the adaptive technology having  no
idea what to watch for.

consequence: you either get too much feedback, or you miss
relevant changes in the interface.

>>>>> "Erik" == Erik Bruchez <ebruchez@orbeon.com> writes:
    Erik>   Stefano Debenedetti wrote:
    Erik> 
    >> It's not the same thing, XForms relevance is a declarative
    >> (i.e. much more easily statically analyzed) way to have
    >> stuff disappear from your page, while a "dynamic HTML DOM
    >> update changing a CSS property" is by definition something
    >> that requires a dynamic engine noticing that stuff may be
    >> subject to disappearing no earlier than at run-time.
    Erik> 
    Erik> Your XForms engine follows a certain processing
    Erik> model. At a certain point, a Model Item Property (MIP)
    Erik> will change and be evaluated. Upon XForms refresh, the
    Erik> XForms engine will be in charge of reflecting the
    Erik> change of the MIP in the model to a change in the
    Erik> visible user interface controls. Some code, somewhere,
    Erik> will translate this declarative MIP into a piece of
    Erik> code saying "please, hide this stuff on screen".
    Erik> 
    Erik> This is exactly the same that will happen with the HTML
    Erik> DOM and CSS properties when a piece of Javascript code
    Erik> says "please, hide this stuff on screen".
    Erik> 
    Erik> If I was to implement a smart (i.e. integrated with a
    Erik> browser, XForms-enabled or not) screen reader, I would
    Erik> probably use the hooks that IE and Firefox doubtless
    Erik> provide in their DOM to detect such visibility
    Erik> changes. Whether the XForms engine tells me "hide this
    Erik> stuff" or whether I have to detect a CSS property
    Erik> change doesn't seem to make much of a difference.
    Erik> 
    Erik> I think the above supports the opinion that
    Erik> "declarative" and "script-less" are primarily important
    Erik> for the developer, but not so much at the
    Erik> implementation level.
    Erik> 
    >> I might be wrong or inaccurate here but I think this is
    >> why Hixie once said XForms is just one step away from
    >> being yet another scriping engine (can't find a link to
    >> that right now sorry) instead of saying XForms is yet
    >> another scripting engine.
    Erik> 
    >> Luckily steps missing still are more than one.
    Erik> 
    Erik> This is not an issue if you don't look at the world
    Erik> with the ideas that "scripting is evil" and therefore
    Erik> "XForms cannot be said to do scripting or we are in big
    Erik> trouble" ;-)
    Erik> 
    Erik> We know that XForms has great features for the
    Erik> developer. It not only formalizes, using declarative
    Erik> markup, some user interface patterns that are often
    Erik> done with Javascript, but it also provides us with a
    Erik> declarative event and actions system, an XML-based data
    Erik> model, a powerful submission mechanism; etc.
    Erik> 
    Erik> But here is where Ian Hickson is right: at some point,
    Erik> you will write something like this:
    Erik> 
    Erik> <xf:action ev:event="xforms-value-changed">
    Erik> <xf:setvalue ref="my/node/a">Hello</xf:setvalue>
    Erik> <xf:send submission="my-submission"/> <xf:setvalue
    Erik> ref="my/node/b"
    Erik> value="instance('some-instance')/node-b"/> <xf:toggle
    Erik> case="ok-case"/> </xf:action>
    Erik> 
    Erik> The above clearly *is* scripting. It doesn't use
    Erik> Javascript as far as the developer is concerned, and it
    Erik> uses a level of semantics above what you usually do
    Erik> with Javascript, but it's imperative scripting
    Erik> nonetheless: it gives the XForms engine instructions
    Erik> that must be executed in a sequential order.
    Erik> 
    Erik> Now I for one don't see anything wrong with that. The
    Erik> set of actions provided by XForms is simple, well
    Erik> thought-out, and the small number of them actually
    Erik> allows you to accomplish, by combination, an amazing
    Erik> number of tasks. Instead of learning hundreds or
    Erik> thousands of Javascript APIs (without talking about the
    Erik> language itself), you get by in a very large number of
    Erik> cases just with those few actions that XForms defines.
    Erik> 
    Erik> This just shows that XForms is not just about
    Erik> declarative vs. imperative: it's also about ease of use
    Erik> for developers, and about removing the temptation to
    Erik> use confusing Javascript.
    Erik> 
    Erik> It also shows that the declarative vs. imperative
    Erik> debate is not necessarily a key to discuss XForms
    Erik> accessibility.
    Erik> 
    >> as stated everywhere from the XForms design goals to all
    >> over this and many other threads about XForms vs. script,
    >> it's supposed to be much easier for implementors (be them
    >> of screen readers or of visual browsers) and for everybody
    >> else too (authors, users) to deal with statically declared
    >> markup (be it HTML or XForms) rather than with
    >> dynamically, imperatively and much more arbitrarily
    >> generated stuff, which could be directly DOM nodes but
    >> that could well be other script tags then generating other
    >> DOM nodes and so on recursively, for example.
    Erik> 
    Erik> But in the end, there is one main thing that matters:
    Erik> the user interface changes, and that's done through DOM
    Erik> updates. Hook-up your screen reader at that level.
    Erik> 
    Erik> Best,
    Erik> 
    Erik> -Erik
    Erik> 
    Erik> -- Orbeon - XForms Everywhere:
    Erik> http://www.orbeon.com/blog/
    Erik> 

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Received on Sunday, 14 May 2006 19:18:59 UTC