Ian Hickson <[EMAIL PROTECTED]> wrote in message > On Thu, 29 Apr 2004, Bryan Taylor wrote:
> This is probably the wrong forum then. Mozilla developers already have > their hands full with more important work like performance, footprint, > and CSS, HTML and DOM support. This was the forum suggested as the most appropriate in the bugzilla thread. The second sentence constains a value judgement that I obviously don't agree with. > It's what the "helpwanted" keyword means. If XForms support was to be > rejected even if a quality implementation was provided, then the bug would > have been marked WONTFIX. Comment #83 questioned whether that keyword was sincere and was never adequately answered in the thread. > Note how Mozilla staff's similar lack of enthusiasm for MNG (a feature > with even more votes than XForms, which might give you some idea of how > meaningless the number of votes the XForms bug has is) has not stopped MNG > developers working to create an MNG implementation that is of good enough > quality for being placed in Mozilla. I can't for the life of me figure out why mozilla chose to even allow voting if the attitude towards it is so dismissive. > > XForms would be a gambit to convert GUI and XML-centric middle-tier > > developers to mozilla for some things that aren't traditional browser > > functionality. If mozilla can simplify life for enterprise systems > > developers even a little, then they will use it, and their users will A) > > have to get mozilla installed and B) be forced to try it. I believe that > > XForms is such an opportunity. At this point, MS and IE are heading for > > XAML and so they aren't likely to try to offer incompatible XForms. This > > means mozilla has an opportunity to have enterprise systems lock in to > > mozilla. > > There is a third option, which is to work on alternatives to XAML that are > much more author friendly (for example, that don't depend on XPath, are > compatible with deployed content) and therefore more likely to succeed. Trying to forge you own standard and rejecting ones like XPath seems neither "author friendly" nor "likely to succeed" to me. Doesn't the IE monopoly make incremental extensions to HTML vitually impossible? > > Is anyone arguing XForms is this "bad" of a standard? > > There have been arguments against XForms, yes. For example XForms received > several "no" votes when it was in the Proposed Recommendation stage at the > W3C. Just out of curiosity, who voted no? > XForms' power simply isn't that needed by internet-Web content much. (It > is certainly possible that it is needed by Int_ra_net Web content, but in > such scenarios the existing XForms plugins are enough, since typically the > deployment of the content can be coordinated with the deployment of > appropriate user agents.) Here's were I think were really getting to the heart. I certainly do agree that a lot of XForms features benefit developerment of enterprise systems that very often would deploy on internal corporate networks. You seem to imply that internet apps should drive mozilla's core capabilities more than intranet apps. Does this follow from mozilla's mission? >From a marketing point of view, the internal corporate network seems to me like a much larger potential mindshare opportunity. If you can get a company to choose mozilla as part of its architeture for its internal systems then it goes on a whole bunch of desktops. A company can require its use internally, while it might be very hesitent to do so on the internet. > Right. Intranet stuff. Quite adequately supported by existing XForms UAs. Your presumption is that intranet use cases are not compelling compared to internet use cases for driving mozilla core capabilities. Why do you believe this? > > If this isn't enough, you could also use XForms to configure any desktop > > app that uses XML config files, and do so remotely with close > > interlinking of help docs and howtos. > > ...which has pretty much nothing to do with the Web. But it could play a role in a potential mozilla and Gnome cross-pollination. It depends on how you define or redefine "the Web". Why shouldn't we put administrative configuration for local and networked resources on "the Web". > > Can you elaborate? How can adding capabilites with a richer event model, > > XForms does not add anything to the event model. Hmm. I may have wrongly assumed that the events needed by XForms (the part in Section 4 of the XForms spec) went beyond what exist now. That is actually good news if true, since the implementation task would be easier if nothing truly new is in Section 4. > > better separation of structure, logic, and layout > > Also known as "more indirection", something that causes authors more > trouble, as shown by the trouble they have with CSS. (I went into this in > more detail in my first reply). To hell with all that design pattern crap, eh? These folks can stick with simple HTML forms (which XForms does NOT take away) and I hope I never have to read or maintain their code. I also wouldn't let them touch any part of my enterprise systems, either. > > and support for XML instance data result in a loss of suitability for > > the typical web app? > > The typical Web app isn't a constraint-based form. > > Look at eBay, for instance. Or games like at voidwars.com. You asked earlier about why XML is great for systems integration. eBay is a great example such a system. Their system runs is an XML message driven, n-tier system that uses J2EE and IBM websphere. The forms you see talk to a backend that ultimately translates everything to XML messages that flow around to various databases. Their web services API is described here: http://developer.ebay.com/DevProgram/developer/faq.asp You could write your own eBay XForms front end (say as part of your purchasing department's purchase order tracking app) that would interact direclty with eBay by submitting XML edited in an XForms page to eBay. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
