On Mon, 2 May 2004, Bryan W. Taylor wrote: > > XML is everywhere in business systems, and it also isn't used enough.
I'll certainly grant you that XML is used in many situations. I certainly do not see any reason to consider XML special in some way though. Sure, there are some data structures that it is very good at describing (annotated trees, in particular). There are also many things that don't fit XML though, it's not the be all and end all of data metaformats. > 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. Just like XML isn't suitable for everything, name value pairs aren't suitable for everything. > 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? There is no reason that all of the above shouldn't work just as well with HTML Forms as with XForms. >> Mozilla developers already have their hands full with more important >> work like performance, footprint, and CSS, HTML and DOM support. > > [This] sentence constains a value judgement that I obviously don't agree > with. You think it is more important to implement XForms than to work on making Mozilla work on smaller hardware such as the mobile devices on which you want to see XForms implemented? You think it is more important to implement XForms than to implement the core standards that _every_ Mozilla user relies on? > Comment #83 questioned whether that keyword was sincere and was never > adequately answered in the thread. A comment in a bug system starting with "Jesus fuck" does not deserve any kind of response and was almost certainly not read by anyone who would be qualified to reply to it. >> 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. The entire reason votes exist is to give users a channel to indicate their support without spamming a bug with useless advocacy comments (like yours). It has no other purpose. >> 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 your own standard and rejecting ones like XPath seems > neither "author friendly" Why is rejecting a complex, poorly-implemented standard such as XPath in favour of a simple widely-deployed technology not author friendly? (This is assuming that the alternative would be developed by several browser vendors together and implemented in parallel.) > nor "likely to succeed" to me. Again, why would XPath (and XForms) have any intrinsicly higher likelihood of succeeding than any other consensus-driven open standard? It seems to me that at the current juncture, the Microsoft proprietary XAML technology is more likely to succeed than XForms (and XPath and XML Schema). Especially if Mozilla et al don't implement anything to counter XAML. So why would rejecting a complex, poorly-implemented standard such as XPath in favour of a simple widely-deployed technology be any less likely to succeed? > Doesn't the IE monopoly make incremental extensions to HTML vitually > impossible? Quite the opposite. The IE monopoly makes non-HTML based solutions impossible to deploy. Note how every XForms form targetted at formsPlayer is actually using text/html as the MIME type, which is invalid. Using IE's many extension mechanisms, such as HTCs, it is possible to create extensions to HTML that work in IE without binary plugins. >>> 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? I believe that information is covered by W3C NDA. > You seem to imply that internet apps should drive mozilla's core > capabilities more than intranet apps. Does this follow from mozilla's > mission? It seems to me that it does: "The mission of the Mozilla project is to preserve choice and innovation on the Internet." Note "Internet". Not Intranet. > From a marketing point of view, the internal corporate network seems > to me like a much larger potential mindshare opportunity. As Brendan pointed out, most corporate networks are not interested in changing to a non-default browser. > 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? Because end users are much more likely to switch to Firefox than corporate policies are to change to requiring a non-default Web UA. >>> 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". This looks like a solution in search of a problem, not vice versa. You want XForms in Mozilla because you think it would make it easier to write Gnome configuration applets? Given the kind of stuff that configuration applets need to do, like browse the local file system, restart services, reflect the state of devices, etc, XForms wouldn't be my first choice for a development platform here. >>> 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. Section 4 is the XForms processing model, not a richer event model. It would probably be a large part of the XForms-specific part of an XForms implementation. It doesn't really gain you much over the equivalents in HTML forms though. >>> 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? Frankly, yes. It's all well and good to have Model-View-Controller type systems for professionals, but there are millions of Web authors who couldn't care less, and shouldn't need to. Blogs, quizzes, forums, search engines, games... these don't need the complexity of multiple levels of indirection. > 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. That's fine. Most Web authors don't _want_ to touch enterprise systems, that's the point. >> 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. That doesn't make XForms suitable for the front end. The forms on ebay.com have few constraints. They are mainly freeform searches. The UI is mainly about having different views and sort orders for their table of richly formatted data. I guess I don't understand what you are trying to convince me of. I acknowledge that XForms is well designed for advanced form needs, which are typical of closed-network systems in the industry. I've spoken to members of the UK Life Insurance industry who are very vocal in their XForms support, as well as people from other industries who also want to use XForms. However, the total size of the market of people who would actually switch to Mozilla (or another non-IE browser) because of its XForms support is minimal, certainly not worth the effort of implementing it. See Brendan's comments for instance, indicating that most companies are not willing to switch away from IE, certainly not just for XForms. This is especially relevant given that IE has a number of quite good plugins that handle XForms well. Similarly, XForms has large issues that offset any benefit that would be gained from implementing it: its many dependencies (the main ones being XPath, XML Events, XML Schema types), and its own size (it requires its own XPath extensions, it changes normal rendering semantics, it uses some CSS pseudo-elements that you have to implement to usefully style XForms, as well as the XForms model and so forth), to name but two. Finally there is the problem that even if browsers had implemented XForms, it would not be suitable for the majority of the Web's forms, given its high complexity and complete lack of backwards compatibility. Now, given all these problems, if XForms is to be implemented, there are three options. Either those people who need XForms support and would use it can do the work themselves (this is, after all, a free software project -- if you have an itch, you scratch it), or they can put their money where their mouth is and pay someone to do it (this is, after all, a capitalist society -- if you want something, you pay for it), or, they can convince some of the existing developers to stop working on what they are doing and do XForms instead. But if you pick the latter, what do you think we should stop working on to do XForms instead? -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.' _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
