This post represents only my personal opinion. On Wed, 27 Apr 2004, Bryan W. Taylor wrote: > > [XForms] is aimed at addressing the gap between thin HTML forms and fat > GUI apps.
It's not clear that this aim hits target, though. It appears to be suitable for people writing professional form-based data entry and workflow systems, as in tax reports, or insurance forms. It doesn't seem to be really suitable for your typical graphical (Web) application. > XForms, much like XUL, provides a set of widgets which can be declared > using an XML language. Unlike XUL, the point here is to allow these > widgets to be bound to an XML data format, so that XML based data can be > submitted. More to the point, it is designed so that the widgets are merely a view on an underlying data model represented by an XML subtree that can then be submitted as XML. > I believe that XForms could actually be the kind of jolt that would > allow Mozilla to get penetration onto some corporate desktops. It is true that there are certain (relatively small) segments of the Web browsing population that would probably use Mozilla if it supported XForms. Seen in the context of the ~0.6 billion Web users, though, this is a very small market. > Let me explain why an XML bound data form is so valuable to > corporations. Especially when multiple databases or business services > are being fed, it is very desirable to have the data in an XML format. Why? > Hopefully I don't have to explain why XML makes enterprise application > integration easier. It is not at all clear to me that it does, so yes, please do. > 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. > 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. > 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. > This is why XForms leverages so many standards -- the use cases where > XForms wins are the ones where you are doing this stuff anyway, but > doing it in the middle layer with custom code, perhaps in multiple > places. 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. 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). > 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. > 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.) > Mozilla as the premier flag waiver of the "standards compliance" > movement should understand that we can have a lot of device vendors as > allies if we implement XForms. To get device vendors as allies, Mozilla would have to quarter its disk and memory footprints, not add new features. > I think that Mozilla should ask three questions about itself when a new > standard shows up to figure out if it makes sense to include in the > browser > > 1) Does the standard have any synergy with mozillas core competency as > an HTML browser? A good question. With XForms, the answer is no -- it does not benefit the average user, nor the average Web author. > 2) Would implementing the standard advance mozilla's mission? A good question as well. With XForms, the answer is again no -- the mission of the Mozilla project is to preserve choice and innovation on the Internet [1], and to do this it needs to compete effectively with Internet Explorer. IE will never implement XForms; Microsoft have stated in no uncertain terms that the way forward for IE is Avalon/XAML. Therefore the way to compete with IE, as far as browser features go, is to provide technologies that are more attractive to the majority of Web developers than Avalon/XAML. One key way to do this is to make the languages easy to use and easy to author for. XForms is neither: it uses multiple levels of indirection, multiple namespaces, XML Schema, XPath, and, probably most importantly, is not backwards compatible with existing content. [1] http://mozilla.org/about/ > 3) Is there user demand and would that demand possibly increase mozilla > deployment? A good question too. In the XForms case, the answer is yes, but not particularily compellingly so. > All three questions are strongly "yes". 1) is easy: HTML has a simple > type of form because data entry has browser synergy. XForms are just a > more advanced data entry that adds value in settings like the > enterprise application space. XForms is not "just a more advanced data entry" format. It's an entirely different model that breaks backwards compatibility, which is mostly not suitable for Mozilla's primary arena, the Web. > To 2) I say Mozilla's mission statement is to be a browser "designed for > standards-compliance, performance and portability". That is not Mozilla's mission, as stated on the Web site quoted above. But even if it was: > XForms assists all three: standards compliance is almost a tautology > since XForms is a W3C standards. Standards compliance is good if it means interoperability. Interoperability is not something that implementing XForms would give us, however, since nobody else in the browser space has implemented it (and several of the other vendors have been quite vocal in their claim that they will never implement it). > Performance of the entire information flow imporves when we move XML > tasks to the client to avoid network round-trips and distribute > processing, Performance of the browser itself drops significantly when it has to implement new standards, and good performance of XForms in particular is not at all a given when you note its dependence on XPath. > and portability is a consequence of XForms design decisions to address > the lack of portability across devices of HTML forms. This is extremely misleading. XForms is _less_ portable than HTML Forms, the latter of which are completely device independent. XForms has a device-specific profile, for example; HTML does not. > To 3) I reiterate my points above about corporate computing wanting XML And I reiterate my point about this not being a given. > and I also note that all kinds of desktop apps for home users do little > more than organize data entry tasks. I have seen no evidence that these applications would be written in XForms if the authors of those applications had the ability to do so. (Quite the opposite -- most people I've spoken to about this tell me XForms looks much too complicated to suit their needs.) > Clearly people agree because there are 534 votes. The MNG bug has over 600 bugs. And there are only (at last count) 300 or so MNGs on the entire Web. Votes don't mean much. 600 votes is roughly one millionth of the total estimated Web population. I don't think one millionth counts as a majority in any world. > Some people object to XForms. Their arguments seem to be: > > A) It's too complicated. It's a bloated committee-created standard with > too many bells and whistles and too little implementation experience. > Big new standards won't be implemented consistently by vendors and won't > have much content for a long time. More to the point: It's too complicated; it's a bloated committee-driven recommendation that average Web authors do not understand how to author because of its reliance on multiple levels of indirection. > B) XForms depends on too many other specs. Implementation is a pain Indeed. > C) Wouldn't it be better to just incrementally improve HTML forms? Indeed. > I believe there is some rationality in all of these criticisms Why thank you. > but I just don't think they are substantial enough to offset any of the > benefits. To A) I say that if XForms, in it's full glory seems too big, > then start by implementing the simplified core of XForms Basic, or some > other subset. XForms Basic is not a simplified core, and to claim it is shows a dramatic misunderstanding of the XForms Basic specification. The only difference of note between XForms and XForms Basic is that the latter does not require full XML Schema support. Other than that, it is still just as bloated. Since XML Schema is not technically part of XForms, taking the requirement out is not much of a change. As far as I can tell -- and I have studied this in some depth! -- there is no way to subset XForms. It's one of XForms' strengths -- it's designed in a very holistic way, where everything fits together in a way where subsetting any one bit would remove almost all the useful functionality. For example the obvious thing to remove is the dependence on XPath, but then there is hardly anything left. > Every W3C recommendation has at least two implementation apps This is a convenient myth. The CR requirements are actually tested by very few working groups, most rely on marketing department claims of support and do not check for whether the applications actually attempt a real implemenation, let alone check whether there is actual interoperability. > so I just don't buy that its so complex that that our weary little > brains will melt. Many authors I have spoken to disagree. The entire concept that your form controls aren't what gets submitted is very difficult for many people to understand. You have to realise that for many people, even the concept of CSS is hard to understand. People ask "how do I make this text blue", not "how do I make all my headers blue". The former is answered by the WYSIWYG mentality, stick in a <font>. The latter is answered by the semantic/style divide mentality, mark up the text as being a header, then add a rule to your stylesheet that maps headers to a colour. In XForms the problem is even worse -- "how do I disable this control?" has the answer "you tell your data model that the relevant subtree is no longer relevant, then you bind your subtree to the control". People's brains dont melt -- they just go elsewhere. > There is a healthy base of implementers out there and a whole community > who wants XForms, so who better to foster dis-ambiguation of the > standard than Mozilla. Maybe the healthy base of implementors and community who want XForms! > This applies equally to B)... people wanted to leverage the other specs > in XForms because enterprise application development has to deal with > that level of complexity anyway and if XForms can do more of the heavy > lifting then it adds value. But most Web-based application development is not the enterprise application development you speak of. It's things like eBay or Amazon. > Besides, if XForms didn't need to deal with XML and all the related > specs, then C) might be valid. But C) is not valid because it > contradicts the mozilla mission to be standards compliant Note that that is not the mission statement. Also note that extending HTML Forms does not need to mean that the extension is not standards compliant. It would be perfectly feasible to extend HTML within the W3C, or at another standards organisation if the W3C was not amicable to such work. > and it wouldn't work anyway unless you can convince IE to implement the > same changes without trying to embrace, extend, and extingish your > improvements. All that would actually be needed would be HTC, JavaScript or CSS based implementations of the technologies in IE, in the same way as Dean Edwards has (impressively) implemented much CSS2 functionality in IE purely using HTCs, JS, and JavaScript in his so-called IE7 project [2]. [2] http://dean.edwards.name/IE7/ > The IE has successfully thwarted incremental improvements to HTML, get > over it. If IE has thwarted incremental improvements to HTML, it must be even more true that IE has thwarted any real effort at using XML in Web browsers. > The only arena in which mozilla can innovate successfully is by > incorporating community supported standards Which community? > ...that have synergy with HTML XForms has _zero_ synergy with HTML. It is in fact completely incompatible with HTML, how can it have any synergy with it? > and add large amounts of new functionality that require open standards. I think saying that Mozilla can only innovate well if it uses standards that add large amounts of new functionality dependent on other standards is to rather miss the point of "innovation". > Standards compliance is the ONLY feature that IE cannot bully mozilla > over. Unless mozilla innovates in the direction of its stregths and its > mission (standards, portability, performance) it cannot compete with IE. Standards compliance is meaningless if it doesn't lead to interoperability. In this case that means Mozilla must support the same standards that other browsers also competing with IE support. XForms is not one of them. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.' _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
