Boris Zbarsky <[EMAIL PROTECTED]> ... > "helpwanted" means just that "help in getting this working is wanted." > I'm not sure how your post helps the situation.
The people who know mozilla don't see the benefit and the people who see the benefit don't know mozilla. Hopefully discussion can change this. > > 1) Does the standard have any synergy with mozillas core competency as > > an HTML browser? > > Not at all. The standard is not even usable with HTML. Huh? Can you explain what you mean by this? See Appendix G.1 "XForms in XHTML" of the XForms spec for an example. See the X-Smiles project for a working reference implementation that hosts XForms with XHTML. http://www.x-smiles.org XForms was designed to be integrated with XHTML in mind. From the XForms abstract: "XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML or SVG." In fact, it will be part of XHTML 2.0. See the XHTML 2.0 working draft (20. XForms Module). > > 2) Would implementing the standard advance mozilla's mission? > > The answer to this is "depends on what Mozilla's mission is". See the "What > are the goal of Mozilla.org?" thread in netscape.public.mozilla.seamonkey. Agreed. the official statement of mozilla's mission is at http://www.mozilla.org/about/ The "we are" statement includes this: "An advocate for standards on the Net who provides tools for developing standard web content." > 4) Are there engineering resources available to implement this feature without > dropping work on something else? > > The answer to that is "No." This can change at any time should someone get the itch who has the time and skills needed. The mozilla leadership can certainly influece people -- things they speak about as important are more likely to have volunteers appear. > 5) If the answer to #4 is "no", then what ongoing work should be dropped in > favor of working on XForms instead? This comes down to perceived costs and benefits. Dropping work on things with poorer cost/benefit ratios would be a good thing. A potential contributor could only benefit from a quality discussion of these costs and benefits. > > To 2) I say Mozilla's mission statement is to be a browser "designed > > for standards-compliance, performance and portability". > > I'm not sure you're in a position to be defining Mozilla's mission statement. > Again, see the "What are the goals of Mozilla.org?" thread. I didn't author that -- it came from the mozilla site in the October-2003 timeframe. There appears to be a totally new statement of mission since then (linked above). Shame on me for not checking to see if it had changed. > > standards compliance is almost a tautology since XForms is a W3C standards. > > It's also not a goal in itself, except insofar as it furthers the goals of the > Web in general and Mozilla.org in particular. Bad standards should NOT be > implemented if they will harm the Web or harm other goals. Consider the story > of the Content-Location header as it played out recently in Mozilla. Is anyone arguing XForms is this "bad" of a standard? The XForms WG appears to have followed a heathly process here. They have had lots of input from a broad base of contributors, three working sample implementations, a publicly available test suite, and work is ongoing. I'm not aware of any alternatives that come close. The choices appear to be use this standard or do nothing. > Clearly, 534 biased people agree. As Asa says when people quote a number like > that, "1 million people downloaded the last Mozilla milestone; you're saying > only 0.05% of them think this bug should be fixed?" I think you know that dividing two unrelated numbers does not have any predictive value. Comparing vote counts between different bugs would have pretty good predictive value as to which is more desired. > I don't think anyone making the "XForms is bloated" comments has seriously > considered implementing all of the thing. They _were_ talking about XForms > Basic. Comment #89 by Mr. Hickson discusses XForms Basic as simplifying the node validation part, replacing XML Schema comparisons with QName comparisons. Other than this there wasn't much discussion of what becomes simpler from an implementation point of view. XForms Basic simplifies XML Events and the Schema validation. Those were the two main sources of the "bloat" argument, which I don't buy anyway. > > Every W3C recommendation has at least two implementation apps > > Name the ones for XForms? There are actually three: X-Smiles, FormsPlayer, and Novell XForms. http://www.w3.org/MarkUp/Forms/Test/ImplementationReport.html If a small project like X-Smiles can implement XForms in full glory, I have trouble believing the specs is too bloated for mozilla. > > There is a healthy base of implementers out there and a whole > community who wants XForms > > And none of them willing to write a line of code? More on this later. Do you mean write code *for mozilla*? They are writing lots of code: http://www.w3.org/MarkUp/Forms/#implementations > > The only arena in which mozilla can innovate successfully is by > > incorporating community supported standards that have synergy with HTML > > and add large amounts of new functionality that require open standards. > > Indeed. It's your claims that XForms fits this description that I > don't quite buy. Well at least we agree on what the elements that would need to be proven are. > In all this, you have carefully avoided a very important question: who > should do the work, exactly? Without an answer to this question, all > this discussion is meaningless. If there are 500-some people who want > to see it, why don't some of them actually make it happen? Obviously the people with the mozilla internals knowledge don't see the benefit and the people who see the benefit don't have the mozilla internals knowledge. The uncontested (and wrong) views of the anti-XForms crowd, IMHO, hurt. > I'd suggest starting with a list of the things that XForms depends on > that would need to be implemented. Once you have compiled such a list, > you may gain some appreciation for the comments of people who DID compile > such a list, looked at it, and decided that they weren't going to get > involved with an endless task like that. If a small project like X-Smiles can do it, then mozilla can do it. It is purely a question of will and motivation. Actually, from reading bugzilla, it sounds like the list is something like this 1) XML events 2) node validation 3) XBL mappings from XForms to mozilla UI widgets 4) generic submission functionality When I look at the XForms specs, the events in section 4 seem like the hard part. A good next step would be to map out how each events there could be handled in mozilla and to map out how the form controls in section 8 translate into XUL/HTML. > P.S. You may want to see > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=7b2095a0360950dd&seekm=c67n14%24oq81%40ripley.netscape.com#link97 > > and continuing. Someone _is_ actually working on XForms in Mozilla, and this > someone may just have the resources to pull it off. But note the "_really_ > long time" part, even given who's doing it. Well, that's good news. It doesn't surprise me that IBM wants to do this. They are, after all the leader in consulting services for enteriprise sysems integration. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
