Unfortunately, this bug has been languishing with the "helpwanted" keyword, making little progress. I'd like to make the case for XForms and hopefully stir up some buzz for it.
What is the point of doing that, if I may ask, except for having the pleasure of hearing yourself talk? "helpwanted" means just that "help in getting this working is wanted." I'm not sure how your post helps the situation.
Nevertheless, I think some of the specious arguments being made should be responded to, so here we go.
I believe that XForms could actually be the kind of jolt that would allow Mozilla to get penetration onto some corporate desktops.
That's very possible, yes. Note that the bug is "helpwanted," not "wontfix."
> You also have to do validations that could
be done on the client and that means crummy performance.
You have to do said validations anyway, unless you have absolute control over all possible clients that could access your server (that is, you have disabled telnet, not installed any of the perl modules that can do networking, hacked your libc to not allow any network-aware C apps to function). Of course if you did that, Mozilla can't access the server either.
Mozilla as the premier flag waiver of the "standards compliance" movement
I'm not sure what makes you think there is such a movement or that Mozilla is a "flag waiver" for it....
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.
Or did you mean "as a CSS browser" (which is what Mozilla is)? Then not much, since the standard doesn't actually use CSS to any great extent.
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.
3) Is there user demand and would that demand possibly increase mozilla deployment?
The answer to this is "yes" (with the strategic "possibly" tossed in there; without it, "maybe").
You forgot a few relevant questions:
4) Are there engineering resources available to implement this feature without
dropping work on something else?The answer to that is "No."
5) If the answer to #4 is "no", then what ongoing work should be dropped in
favor of working on XForms instead?XForms are just a more advanced data entry that adds value in settings like the enterprise application space.
IF this is all XForms were we wouldn't be having this discussion. The problem is, it's not.
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.
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.
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 can't quite recall whether this was in that nice list of "common logical fallacies" I was taught in high school, but if it wasn't it should be added.
Clearly people agree because there are 534 votes.
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?"
For the rest, I think David's comments on this number are spot on target.
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,
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.
or some other subset.
Please define that subset; then we can talk. The XForms WG has deemed that no subset smaller than XForms Basic is worth implementing, apparently.
Every W3C recommendation has at least two implementation apps
Name the ones for XForms?
Also, note that some specs are much easier to implement in one environment than in another. For example, CSS3 Selectors are much easier to do if you know your DOM will never change and there will be no user interaction whatsoever. So you can have two implementations, interoperable even, which simply ignore a lot of the complexity inherent in implementing the same standard in a different environment (eg CSS3 Selectors in a web browser).
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.
so who better to foster dis-ambiguation of the standard than Mozilla.
I'm not sure what this sentence means, and I'm not sure you're sure either.
B)... people wanted to leverage the other specs in XForms because enterprise application devlepment has to deal with that
[etc]
We know WHY they did it. That doesn't change the fact that it makes XForms dependent on a whole bunch of complicated stuff. Again, more on this later.
But C) is not valid because it contradicts the mozilla mission to be standards compliant
See above on the Mozilla mission.
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.
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?
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.
In any case, once you have this list, I suggest you estimate how long it will take (in person-time units; I suspect the relevant unit of measure will be person-months at least, assuming full-time developers).
Then make up a list of the current Mozilla.org work that should be dropped to free up the resources needed.
Then see whether the idea still makes sense.
-Boris
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.
_______________________________________________
mozilla-layout mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-layout
