Ian Hickson <[EMAIL PROTECTED]> wrote: > On Wed, 27 Apr 2004, Bryan W. Taylor wrote: > > In an HTML form setting, you have to write a lot of middle-tier code to > > bind the data elements of a submitted form to your targetting XML > > format. > > You are assuming the existence of such an XML format. You are assuming > that writing such binding code is anything other than trivial (it's not -- > mapping a structured-name/value pair list to XML is very easy). You are > assuming that the code that is part of the XForms document is less > involved than the code that would be used to map name/value pairs to XML.
XML is everywhere in business systems, and it also isn't used enough. See some of the sources I discussed in the previous post for examples. Your name value pairs argument is interesting. Is it not equivalent to the proposition that all data is trivially equivalent to a string-to-string hash? If name value pairs trivial for everything, there would have been no need for XML, we would just use name value pairs for everything. We'd end up with names looking like XPath and values that had to It only trivial to map flat data to a heirarchy when the number of data elements is small and the target structure is simple enough that the needed naming convention is also trivial. Which, I suppose, describes the set of data structures that can be produced using simple HTML forms. If somebody hands you their XML format with attributes and mixed content and various data types, then your name value pair mapping is going to look a lot like XPath for its names and some weird kind of data type thingy for values. HTML web apps are characterized by excessively editable data and too much page to page navigation, so you've also got to factor the page flow and naming convention to support it into your naming convention too. > > You also have to do validations that could be done on the client > > and that means crummy performance. > > XForms does not in any way alleviate this since the server can never trust > the client and therefore has to do all the validation anyway. > Indeed XForms validation arguably _increases_ the amount of validation > that is required since you now have to do it on both the client side _and_ > the server side instead of just one. Not true for two reasons. "All" the validation includes multiple passes during the edit-validate-fix cycle. Each pass done on the client avoids round trips to the server. Once the data is clean, then it'll revalidate zero or one times on the server, depending on whether our security measures: user autentication, firewalls, transaction traceability, and general policies allow us to treat our users as trusted or not. Second, if we have untrusted clients, the error handling from failing server validation when we know we have client side validation is much simpler -- we just say "try again" and let the client sort out the specifics. This should never happen unless the client is intentionally circumvented. > > XForms is powerful enough to displace a lot of this work. > > Displace -- yes. It moves the work from one type of code to another > (namely, to the XForms layer). It doesn't reduce the work though. Even if you thought it was break even on programming workload, the performance benefits would win over traditional HTML forms to Mozilla/XForms. But I don't agree it's the same workload. Declarative markup is simpler for these tasks and it's just easier to work with XPath, XML Schema, and XForms than their equivalents that don't use markup. > Whether you write your relationships in XPath or in Perl does not seem to > make a great deal of difference in the end -- you are just moving from one > toolset to another. That's quite egalitarian. You seem to imply that all toolsets are equal at all tasks. I recently wrote a script to solve a problem at work in XSLT. The result was shorter, faster, clearer, and easier to write than the script it replaced, which was written in an open source scripting language (that might as well have been perl). > Note that XForms' leveraging of so many standards is one of its main > downfalls as far as implementations go (you have to implement god only > knows how many specs before XForms is even on the radar). >From the bugzilla comments, I gathered that the gaps for mozilla are: XML events, and parts of XML Schema. What other gaps are there? I would think Schema would have value on its own merits. > > That's the back-end argument. There is a front-end argument too. > > Invariably somebody comes along and says "gosh, can we do the data > > entry on our mobile devices" and then your have to produce a whole > > separate presentation layer which runs up costs. > > This is incorrect. HTML is widely supported on mobile devices, more so > than XForms, and therefore the same layer can be used on both mobile and > desktop devices. How exactly does this work on mobile devices that don't have network connectivity at the moment? How do I hook an HTML form submission into a local message queue? What about mobile devices that use WAP? What about ones that don't even have screens and use VoiceXML? I can't really present this point any better than Oracle does here: http://otn.oracle.com/oramag/oracle/03-may/o33industry.html > > XForms solves this problem because it is designed to be much more device > > independent than HTML forms. > > This is completely untrue. XForms is significantly harder to implement on > devices than HTML. (I work for a company that writes software for mobile > devices and has examined both HTML and XForms in this context, so I speak > from experience.) Whether it is easier to implement XForms or HTML on a device is a different matter than whether if you have both implemented it is easier for form creaters to write device independent forms with XForms. I've used HTML forms on small screens, and it is often a pain from a data entry point of view. Also, you have to have network connectivity at submit time -- there no easy way to use messaging for offline data entry. But XForms is already supported on several device platfroms and more are on the way. An example besides Oracle's is the Handwise implementation for Microsoft CE or Symbian OS, called XFUI: http://www.handwise.com/Services/XFUI.html All I can say is that the companies that target mobile devices are the ones who wanted XForms abstract UI controls and a clean separation of data and UI and who tout these aspects of the spec as enabling greater device independence. I think these design goals obviously help achieve this result. > To get device vendors as allies, Mozilla would have to quarter its disk > and memory footprints, not add new features. How about just using the same open standards that they can use? Allies doesn't mean that they have to use mozilla on their devices. It just means that their customers can write high quality apps that play well on both platforms. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
