RE: XForms Myths Exposed - By Ian Hixie (Opera)

  "... Hixie wins no points for saying that the non-declarative
  aspects of XForms are not declarative -- what he should really
  address is the truly declarative aspects of XForms, and say why
  he objects to them and would rather use spaghetti JavaScript in
  an attempt to achieve the same ends."

  ...

  "The key point is that how you do the checking is extremely likely
  to be different from how I do it, and when you do it will again be
  different from me. We can be pretty sure that we both used JavaScript
  since there is no other way to do it in HTML -- although we could
  have delegated the checking to the server -- but more than that we
  can't say. And if a machine looked at our HTML pages it would have
  trouble working out exactly which bit of script does the checking and
  when, since it would need to understand what the script was doing.
  (Try looking at the source for Google's Gmail or mapping site, and
  imagine writing an automated process that 'understands' what the code
  is doing.)"


Each of Hixie's 'myths' is discussed on my blog in 'The "XForms Myth" Myth',
at:

  <http://internet-apps.blogspot.com/2005/03/xforms-myth-myth.html>

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of Gerald Bauer
> Sent: 10 March 2005 01:24
> To: www-forms@w3.org
> Subject: XForms Myths Exposed - By Ian Hixie (Opera)
> 
> 
> Hello,
> 
>   Ian Hixie writes in the blog story titled "XForms
> myths":
> 
>   I'm getting tired of hearing XForms advocates say things 
> that are either misleading or clearly wrong, so here's a 
> quick list of myths, or misleading truths, about XForms, 
> which I have heard recently (most particularly during the 
> multiple demos of XForms software at the plenary in Boston last week).
> 
> XForms is declarative
> 
>     XForms has declarative aspects, just like HTML.
> But it isn't exclusively declarative. XForms in fact 
> introduces a primitive XML-based scripting language (called 
> XForms Actions) to perform imperative actions.
> 
>     For example, you can use the setfocus element to set the 
> focus to another element, or the load element to make the UA 
> follow a link.
> 
>  Scripting is bad for accessibility
> 
>     False. Scripting doesn't hurt accessibility. What hurts 
> accessibility is when semantically meaningless elements are 
> given some sort of device-specific behaviour (for example, 
> making a div into a checkbox or a scrollbar, or using the 
> font element for headers).
> 
>   Script is harder to maintain than XPath expressions
> 
>     False. It depends entirely on what you're doing.
> The reason most JavaScript on the Web is a mess is because it 
> is badly written; the same would happen to XPath if the same 
> authors used that instead.
> 
>   HTML mixes presentation and content  XForms doesn't
> 
>     False. HTML doesn't mix presentation and content  
> authors do. XForms doesn't prevent the two from being mixed, 
> in fact one of the big things people are pushing these days 
> is SVG+XForms, which is the ultimate mix of presentation and content.
> 
>   XForms is better than HTML because it is media-independent
> 
>     False. Both HTML and XForms are as
> media-independent as each other. If XForms is better it has 
> nothing to do with one or the other being media-independent.
> 
>   HTML mainly specifies how the control should look, while 
> XForms specifies what the control should do
> 
>     False. HTML doesn't specify how the controls should look at all.
> 
>   HTML has limitations, so it had to be replaced with XForms
> 
>     False. It's easier to fix HTML than to replace it with an 
> entirely new language.
> 
>   HTML requires authors to use hacks; XForms doesn't because 
> is cleanly designed
> 
>     False. HTML doesn't require authors to use hacks, browser 
> bugs do. And there's no reason to believe that XForms UAs 
> will be any less buggy than HTML UAs, if it's the same 
> programmers writing both UAs.
> 
>  To demonstrate some of these points, I took the XForms 
> Calculator example, which was used as an example of some of 
> XForms' power at the W3C Plenary last week, and made an HTML version.
> 
> Note that I didn't fix any of the bugs in the sample  there 
> are a number of ways in which this demo is broken. I just 
> converted the existing
> HTML1+XForms+XForms Actions+XPath to the exact
> equivalent HTML4+JavaScript+DOM to see how it would compare.
> 
>   More @ http://ln.hixie.ch/?start=1110316686&count=1
> 
>   What's your take? Do you think XForms "clean" design is 
> overhyped and it's "declarative" XML is just super-verbose 
> scripting in disguise?
> 
>    - Gerald   
> 
> _____________________________________
> XUL News Wire - http://xulnews.com
> XUL Alliance  - http://xulalliance.org
> 
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca
> 
> 
>

Received on Thursday, 10 March 2005 14:26:12 UTC