- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 28 Apr 2007 22:58:01 -0700
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: Dave Raggett <dsr@w3.org>, Matthew Raymond <mattraymond@earthlink.net>, public-html@w3.org, Sebastian Schnitzenbaumer <sebastian@dreamlab.net>
On Apr 28, 2007, at 7:42 PM, John Boyer wrote: > > Hi Maciej, > > The analogy was exactly the right one. Please try again. The > hybrid approach in XForms is another technology for solving the > same problems more easily than using an imperative script approach > alone, just like the script approach is more desirable than writing > it in machine language. > > You've looked around and found that you don't see the need for the > better solution because, you say, no one is using the new solutions > right now in their existing solutions. I don't think that's an accurate description of my remarks. My main point is: it appears that current forms use cases on the web would not benefit from a declarative expression language. As a secondary point, even current forms that might be able to benefit from more declarative features do not tend to use the ones available. > The existing solutions use just plain javascript because that's > all they have right now. That doesn't seem to be the case. FormsPlayer and the XForms Transitional prototype are two alternatives. I'd like to see some success for the existing plugin- or library-based solutions before we decided that the technology is proven enough to go into the core of HTML. > We're trying to talk about a better way to do things that makes it > possible to do current things more easily and to do even harder > things that would be quite hard to do with existing challenges. > Just like using electricity and a light bulb is better than using a > torch, even for reading something as antiquated as reading a book. I recognize you're trying to talk about that. but I don't think your proposed solution (declarative expression language) addresses the problems people are actually having on the web. To continue your analogy, a light bulb is better than a torch, unless your problem was actually to set things on fire, not to provide light. In which case it is over-engineered and unhelpful. > And the use cases you listed here (http://esw.w3.org/topic/HTML/ > FormsUseCases) are pretty trivial. They may sound trivial to you, but these are the kinds of forms that are authored every day and used by people all the time. And many of them don't work as well for users and developers as the best desktop application technology. Anything we can do to improve those kinds of experiences is extremely high leverage. So for you to be dismissive of these use cases makes me think you may be out of touch with how forms are actually used on the web. > And yes people in many verticals (government, financial, insurance, > healthcare, etc.) do in fact want to have a more usable forms > technology, and their requirements really are more complex than the > use cases you are looking at. It sounds like a specialized single-purpose technology like XForms is just thing thing for those verticals. But it doesn't sound like those same features are essential in HTML, the general-purpose language of the web. HTML should include basic building blocks, and specific solutions for common use cases. It shouldn't add special features for relatively rare use cases, and ones that mostly won't come up on the public web. Separate technologies are a better way to deliver special- purpose features. Regards, Maciej
Received on Sunday, 29 April 2007 05:58:22 UTC