The people who know mozilla don't see the benefit
I'm not sure what makes you say that. The people who've commented in the XForms bug all certainly see the benefits; they just feel that those benefits do not justify the costs that would need to be incurred.
and the people who see the benefit don't know mozilla. Hopefully discussion
> can change this.
Which aspect of it, exactly? I see a lot of effort made to convince people who know Mozilla that the best way to invest their time is to implement XForms. I see very little attempt on the part of people who "see the benefits" to learn anything about Mozilla and actually implement anything.
Not at all. The standard is not even usable with HTML.
Huh? Can you explain what you mean by this?
Of course. XForms is only usable in an XML document. HTML is not XML. So you cannot use XForms in HTML.
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
You can only use XForms in XHTML sent as application/xhtml+xml. Which is not supported by IE, hence not usable in the real world. Again, not usable in _HTML_.
XForms was designed to be integrated with XHTML in mind.
You seem to be under the misperception that XHTML is HTML. It's not. There's a rather long list of differences, in fact...
In fact, it will be part of XHTML 2.0. See the XHTML 2.0 working draft (20. XForms Module).
Frankly, my opinion of XHTML 2.0 is even lower than that of XForms. In large part, this is due to the fact that the XHTML working group has pretty consistently ignored every decent suggestion I've seen made for that spec and are NOT addressing the issues that really need addressing in XHTML (for example, the behavior of <object> is so utterly underspecified as to make interoperable implementation impossible). So please, let's not drag XHTML 2.0 into this discussion.
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/
Did you read the thread I pointed to? Especially the part where I explain why that statement is useless as an actual goal?
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.
This is the key -- finding such people. Good luck.
The mozilla leadership can certainly influece people -- things they speak about
> as important are more likely to have volunteers appear.
I think they've pretty clearly said that XForms are wanted. That's why it's "helpwanted". I'm not sure how volunteers are expected to "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.
OK. Let's make this a little more down to earth. Look over the list of checkins I have made over the last two years. Select 4/5 of them to discard. Assume that I'd been working on an XForms implementation instead of doing that work. I may have something limping along by now. Maybe. (I rather doubt, myself, that that would have been enough time for me to do it.)
Then tell me what the cost/benefit ratios are.
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.
Things have changed somewhat since then...
>>standards compliance is almost a tautology since XForms is a W3C standards.
>Bad standards should NOT be implemented if they will harm the Web
Is anyone arguing XForms is this "bad" of a standard?
I've seen a few people make that argument, yes. I don't feel it's that bad, myself, but I don't think it's so great either.
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.
There are some extensions to HTML forms proposed that would be a reasonable middle ground, actually..
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.
Indeed. Neither does quoting any number derived from bugzilla, actually. Same for any other Web poll.
Comparing vote counts between different bugs would have pretty good predictive value as to which is more desired.
Not given the fact that people campaign for this bug but not others.
Also not given the fact that people don't vote for bugs that are desired but look likely to be fixed anyway (eg crash bugs). Or do you seriously think that crash fixes are less desirable than an XForms implementation?
Name the ones for XForms?
There are actually three: X-Smiles, FormsPlayer, and Novell XForms. http://www.w3.org/MarkUp/Forms/Test/ImplementationReport.html
OK. I'll look at this.
If a small project like X-Smiles can implement XForms in full glory, I have trouble believing the specs is too bloated for mozilla.
Actually, implementing something like this in a small codebase is a lot easier -- it doesn't have to interact with nearly as many systems, which simplifies implementation and testing an enormous amount. Also, in a smaller codebase it's easier to use an off-the-shelf library to offload some of the work, whereas in mozilla integration of such a library into the general codebase could be painful (and due to the rather liberal Mozilla license and the rather restrictive licenses of a number of libraries may even be impossible).
And none of them willing to write a line of code? More on this later.
Do you mean write code *for mozilla*?
Yes. If there are all these people who want this in Mozilla, why not put their code where their mouths are?
Obviously the people with the mozilla internals knowledge don't see the benefit
As I said at the start of the mail, you're wrong here.
and the people who see the benefit don't have the mozilla internals knowledge.
Which they could gain, if desired.
The uncontested (and wrong) views of the anti-XForms crowd, IMHO, hurt.
You have yet to prove any of those views wrong....
If a small project like X-Smiles can do it, then mozilla can do it.
See my comments above.
Actually, from reading bugzilla, it sounds like the list is something
like this
1) XML events
And interaction of such with general DOM manipulation, other types of DOM events, etc.
2) node validation
You mean schema support? Or a validating XML parser?
3) XBL mappings from XForms to mozilla UI widgets
This is not that bad, probably...
4) generic submission functionality
This is also probably not that bad.
Well, that's good news. It doesn't surprise me that IBM wants to do this.
Doesn't surprise me either. They may actually be able to make use of it.
>>>>Performance of the entire information flow imporves when we move XML >>>>tasks to the client to avoid network round-trips and distribute processing >>> >>> Very admirable use of "performance" to refer to two totally different things >>> here. > > I have no idea what you are talking about. "Performance" concerns the > efficiency of the use of any particular resource.
First, you quote that Mozilla's goal include browser performance. Then you claim that data flow "performance" furthers this goal. Those are two totally disconnected concepts that you chose to lump together because they happen to have the same label in your mind.
-Boris _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
