Re: About the Web Forms 2 proposal

On Apr 28, 2007, at 5:29 PM, John Boyer wrote:

> I think you missed the point about the declarative vs. imperative
> debate, and then got it later in the email, so I won't go into that.
>

Whether Maciej missed the point or not, I generally agree with his
observations.

XForms is effectively a domain-specific language meant to address a specific
problem.  I am quite glad XForms exists as an exploration of one particular
approach to solving a general problem.  On the other hand, I am less than
convinced that XForms is the "one true way" and merits incorporation into
the base HTML standard.

(Anyone remember "5th Generation" computing?  How many folk are fluent in
Prolog?  Turns out the Japanese did not take over the computing world.
Clearly this was not the Henry Ford/Thomas Edison evolutionary branch.)

XForms may prove the main evolutionary path, a dead end, or one of a number
of healthy branches (of which I suspect the last is more likely).

I think the question in the context of this HTML WG is if or how much of
XForms makes it's way into the base HTML standard.



On 4/28/07, Maciej Stachowiak <mjs@apple.com> wrote:

> > Looking only at the forms that showed up as popular in your web
> > survey is looking in the wrong place to find out how to solve forms
> > problems because you're only looking at the things people know how
> > to do easily as evidenced by the fact that they have done it
> > often.  You will not find too many examples of the forms we would
> > like for people to be able to build because they don't build them
> > as often.  And they don't build them as often because it is too
> > hard and they give up.
> >
> > I can see an argument like yours being made to Henry Ford or Thomas
> > Edison.  "Hi, everyone is traveling with horse drawn carriage and I
> > don't see anyone driving around in a purely mechanical object so
> > there must not be a need for an automobile" or "Hi, everyone seems
> > to be reading using sunlight or torchlight; I don't see anyone
> > trying to use glass, tungsten and an inert gas to read, so there
> > must not be a need for a light bulb."  It makes no sense!
>
> I think you are making a false analogy and overall a fallacious
> argument. Your analogy confuses two separate things, use cases and
> technologies that fulfill them. My personal standard for technologies
> is that if a use-case is popular, but current technologies make it
> hard to do well, then it is worth looking at improvements or new
> technologies.
>
> "Land travel between two points" is a use case. "Horse-drawn
> carriage" and "automobile" are technologies that fulfill that use
> case. So by my standard the high popularity of "horse-drawn carriage"
> is actually positive evidence in favor of "automobile", if we believe
> it will fulfill the use case better.
>
> Let's bring this back to the web for a moment. Video on the web is
> hard to do well. Approaches to it integrate poorly with the rest of
> your content, and rely on external technologies that must often be
> separately downloaded, such as QuickTime, Flash, Windows Media or
> RealPlayer. Yet despite this, it is immensely popular. The fact that
> it is hard hasn't stopped people from doing it, because users want
> it. So this is a good case for enhancing the basic web technology to
> make the experience better for authors and users.
>
> Contrast this to forms that could benefit from declarative
> expressions. We've agreed that the way forms are used today on the
> web, most would not benefit. Now, it is possible that there is an
> untapped hidden demand for such forms but they are just too hard to
> do. But I think this is unlikely.
>
> When users want something, web developers tend to provide it, even if
> it is hard. Besides video, here are some other things that are hard
> to do well on the web that are still becoming fairly popular:
> animated UI elements, rich text editing, updating page state without
> a full page load, drag-and-drop and dynamic client-side graphics.
> Clearly mere difficulty is not an obstacle.
>
> Furthermore, declarative expressions are available on the web today,
> if somewhat inconveniently. XForms plugins are available, and Dave
> Raggett's XForms Transitional prototype shows that declarative
> features can be provided through a script library. I haven't run into
> a website that uses either, except for demo purposes.
>
> These factors make me doubt that there is a large untapped demand.
> Now, maybe there is evidence to the contrary. But to add a
> singificant new functionality to HTML, I think we need to actually
> establish that it would be helpful for things lots of people want to
> do on the web. We can't add every feature, and complex features
> especially need to justify themselves. Adding a complex feature that
> won't actually be used a lot is a significant opportunity cost, so it
> needs to have a clear benefit.
>
> > Finally, it sounds like you don't have much experience trying to
> > develop a larger, more complicated form when you claim that
> > expressions only make things easier  in toy forms.  Have you ever
> > tried to put an insurance or financial application online?  If you
> > ever do, you will begin to understand why we want expressions.
>
> You're right that I have not spent a lot of time developing forms.
> But I have spent a lot of time studying the forms developed by others
> and deployed on the web, particularly cases where they malfunction.
> Insurance and financial applications are not in fact very common on
> the web, and I don't see a declarative expression feature changing
> that. They're not very popular because they are not the kind of thing
> most people want to do a lot, not because they are hard.
>