Closed
Bug 97806
(xforms)
Opened 23 years ago
Closed 11 years ago
Implement W3C XForms in browser and composer
Categories
(Core Graveyard :: XForms, enhancement, P4)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: mdubinko, Unassigned)
References
()
Details
(Keywords: helpwanted, intl, Whiteboard: DO NOT COMMENT unless you're helping implement this)
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 BuildID: N/A "XForms" is the new W3C standard for web forms, including XML form data input and output, new user interface controls, better accessibility, built-in calculations, and eliminates the need for script in most cases. Please vote for this bug if you are interested in seeing XForms implemented in Mozilla. The spec is at http://www.w3.org/TR/xforms/
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•23 years ago
|
||
Setting up dependencies.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
Comment 5•22 years ago
|
||
removing myself from the cc list
Updated•22 years ago
|
Alias: xforms
Comment 6•22 years ago
|
||
I no longer work for AOL, and am certainly not going to have time to implement something this large as a volunteer. Someone else should take this.
Comment 7•22 years ago
|
||
Reflecting reality.
Assignee: hyatt → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: mozilla1.2alpha → Future
Comment 8•22 years ago
|
||
*** Bug 162200 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
Obviously we can't really do this until XForms becomes a Recommendation. Currently it's a Working Draft...
Comment 10•22 years ago
|
||
I think work on this could well be started as soon as XForms reaches Candidate Recommendation status. If W3C is really going to apply the new policy of having at least 2 implementations of the CR before advancing anything to Recommendation status, the process of getting XForms widely accepted could be significantly sped up by having Mozilla join the effort in the CR phase. Besides, I find it unlikely that the XForms spec is going to change much after CR anyway...
Comment 11•22 years ago
|
||
Yes, but it is the last working draft. XForms is a huge spec and it will take some time to finish.
Comment 12•22 years ago
|
||
I really think this is an non-issue. The chances of major changes in the spec at
this point are extremely low, and they are planning on moving to CR very quickly.
From the XForms mailing list:
> The W3C yesterday released a new XForms WD. This
> WD incorporates the last call comments. Review period
> ends Sept 4, the document is then intended to advance to
> Candidate Recommendation.
Comment 13•22 years ago
|
||
DOM Level 2 for HTML was at Proposed Recommendation, then yanked back to Working Draft where it stayed for well over a year. I understand there were some serious objections raised, which caused it to lose ground. Bottom line: if it's not a Recommendation, it's not official; it's not "1.0". Of course, you could start work on it as you wish, but be prepared for it to change beneath you. What would be best for work to start on it is for someone interested in implementing XForms in Mozilla to accept this bug and start coding.
Comment 14•22 years ago
|
||
> DOM Level 2 for HTML was at Proposed Recommendation, then yanked back to > Working Draft where it stayed for well over a year. Which is why I said "extremely low" rather than "non-existent". It can happen that there is a major change this late in the game, but it is rare. > Of course, you could start work on it as you wish, but be prepared for it to > change beneath you. And be prepared for lightning to strike you, too. I once knew a guy who was struck by lightning twice! Seriously, life is filled with uncertainties. Even a 1.0 spec is no guarantee that everything won't change completely with the next spec revision. You don't want to work on anything until a spec is formally completed. Fair enough. Not everyone is so risk averse. Your original statement: > Obviously we can't really do this until XForms becomes a Recommendation. is false, at least for most definitions of "really do this".
Comment 16•22 years ago
|
||
ccing jkeiser, who should have been cced from the start, esp. since he thinks 99% of XForms is a major mistake and should never be implemented in Mozilla.
Comment 17•22 years ago
|
||
Heh, tiny overstatement. But it seems I haven't missed much by not being CC'd ;) XForms have some really great ideas, in a wrapper that is hard for web developers to use and for implementors to do efficiently. XForms can be saved and made implementable and usable by cutting some features and changing others. The real problem is there is no point in completely re-speccing HTML forms from the ground up. The really good ideas from XForms can be put into the existing forms (all of it can be done without any change to existing architecture, in fact--just addition of events, tags and attributes and maybe the deprecation of the name element) and if you do that, web developers will be able to leverage their existing knowledge and add new tools to their repertoire. The current specs aren't *bad*, just inadequate. I am writing a review of the spec--I'm about 70% of the way through it, I'll post to XForms when I've finished. But even if they fix everything, I am skeptical of the need for XForms to redo everything with a new coat of paint and some extra doodads--add the doodads and lose the paint, and you'll have something existing developers can use.
Comment 18•22 years ago
|
||
I think John Keiser has an excellent point - maybe the best option is to make HTML forms better. Maybe xforms could be then be implemented on top of improved HTML forms (if anyone wants to). mozquito.com already uses javascript and HTML to implement xforms to some extent.
Comment 19•22 years ago
|
||
Why not implement XFDL instead of XForms ;-) At least it's a working one. And there is at least one implementation to follow...
Comment 20•22 years ago
|
||
I disagree with John Keiser. How does one person's opinion completely overshadow the collective and collaborative effort of the xforms working group and the members of the www-forms list community? I find that quite arrogant. If we all followed John's and Todd's perspective, then why have XML and its namespaces at all for web development? Why not just do it all in html and keep extending html. Sure, html forms are not broken, but does forms functionality belong in html any more than formatting or scalable graphics? The new approach is to use XML and extend orthogonally using namespaces. In my opinion, Mozilla's architecture lends itself well to grow along these lines much more so than other browsers. XForms is not a "wrapper"; rather, it is a module designed to be hosted by another language. Thus far, there has only been integration into xhtml. Those of us already implementing xforms processors realize that it is implementable and usable and not gratuitous. Besides, it's not John's decision whether Mozilla implements XForms. He may decide or influence Netscape's stance regarding it. However, Mozilla is an open source beast now, and other users/developers are free to contribute. Is it really a good idea for the Mozilla project to start passing judgement over the W3C recommendations and start developing their own standards like has been done in the past by Netscape and Microsoft? Isn't one of the goals of Mozilla to be standards-compliant?
Comment 21•22 years ago
|
||
ddennedy: jkeiser was clearly just giving his own opinions, and there's nothing "arrogant" about that, unless you think the w3c's working groups cannot be questioned, or their efforts criticized. If he's right in his concrete technical claims, then it doesn't matter how big the collective army arrayed against him is; argument from authority is a fallacy. XForms is a classic _de jure_ standard: designed by committee to a large extent, not implemented in an available, widely-distributed codebase or program, and therefore untested in the crucible of real-world, large scale web development communities. Those are facts, as far as I can tell, and not my opinions. I hope hyatt@apple.com will comment too, as he has worked with the XForms wg in the past. My opinion, and I'm a founding member of mozilla.org and the perpetrator of JavaScript, is that standards committees do not innovate well. As Dr. Johnson said of a manuscript that was both "good and original, what is good is not original, and what is original is not good." Consensus leads to bloat, while committee members find it hard to refrain from gratuitous reworking of syntax and other superficial details, as often disimproving as improving by picking mere nits and quirks. Another design-by-committee pitfall: over-layered and under-tested architectures with too minimal a first layer, and progressively more complicated layers and interactions between layers, again finalized in advance of implementation and programmer/web-author usability testing. I'm glad you like XForms, and that you are implementing it. The wg needs more implementors like you. Please don't take my opinions about _de jure_ standards personally, if you happen to be on the wg, or know people who are. I know I'm not better than anyone else active in a w3c wg: I would fall into d-b-c traps too, if I were on a committee. I've been there and done that in the ECMA-262 working group, and in past lives with other standards bodies. Apart from design-by-committee facts and opinions, and here I can speak for staff@mozilla.org, Mozilla is *not* bound to be "standards compliant" with any w3c unfinalized *or finalized* recommendation that fails to meet the approval of Mozilla's module peers, module owners, super-reviewers, and (ultimately) drivers@mozilla.org. We can and should use our judgment and experience when evaluating XForms, and one valid possible outcome (that does not make us "anti-standards-compliance") is not to implement it yet, and not to take a contributed implementation as part of the default build and configuration of Mozilla -- if we're wrong, we'll be forced to revisit such a decision soon enough (no one should dream that lack of support by Mozilla for XForms will be fatal to the success of XForms in the marketplace). If Mozilla peers, owners, et al., reach a consensus against Xforms, we should certainly register our reasons for not doing it with the wg. /be
Speaking for myself as exactly one member of drivers@mozilla.org, I would find it hard to resist distributing a contributed implementation of XForms in Mozilla --- whatever the merits of the final recommendation --- if the code was nonintrusive and the performance impact on non-XForms code negligible. (An XBL implementation would be nonintrusive; a new chunk added to layout would be intrusive :-).)
Reporter | ||
Comment 23•22 years ago
|
||
Brendan, thanks for commenting. Here's a few more things to chew on. The W3C (deservedly, IMHO) is getting a reputation for producing barely implementable specifications that miss the 80/20 mark by a light year. But folks should be careful about making this assumption about XForms. >XForms is a classic _de jure_ standard: With respect, I would be careful about making such a statement. One thing the Working Group prides itself on is 'reducing existing practice to markup'. At least that's how I've presented it at conferences. For instance, instead of script for document.formname.fieldname.focus(), there is <xforms:setfocus>, and instead of 50 'value' attributes scattered throughout the form, initial form data can come from a single XML file. >not implemented in an available, widely-distributed codebase or program Well, I have four client-side, in-progress-but-largely-complete, implementations here. Two of them are public today. There are more coming. The current spec is certainly not perfect. That's exactly why Mozilla should implement XForms during the "Candidate Recommendaton" phase (which the latest draft indicates is coming quite soon). Another thing the W3C is gaining a reputation for is cramming specs out the door without listening to the public. Again, the Working Group members are exerting themselves to counter that trend. It took seven months to get through Last Call because we actually listened to and discussed the merit every single public comment. The primary responsibility of a Working Group should be to represent the public interest. For the immediate future, I don't expect Mozilla to make a hard commitment to implement 100% of XForms (or any standard, finished or not). But I would like to see some "proof of concept" activity, to help spot problems before it's too late. If anyone thinks they could help with this, even in some small way, please send me email.
Comment 24•22 years ago
|
||
jkeiser:
>The real problem is there is no point in completely re-speccing HTML forms from
>the ground up. The really good ideas from XForms can be put into the existing
May I remind the Mozilla community that the AOL/Netscape/Sun alliance has had a
representative on the W3C XForms committee for quite some time, and
additionally a representative on the HTML committee, which created the original
requirements for developing XForms?
The XForms charter, requirements documents, and drafts have been developed in a
process that was included both representation from W3C consortium members and
from the public.
If the Mozilla community finds that a World-Wide Web Consortium spec's
requirements or goals are not to their liking, perhaps they should have
participated in development of the requirements and specifications.
Comment 25•22 years ago
|
||
John Keiser suggests adding Xforms features to HTML forms instead of going to XForms. Why not do this and then provide a way of transforming an xform into the new HTML form - using XLST or whatever? Give me the best of both worlds - I want it all.
Comment 26•22 years ago
|
||
Micah wrote >For the immediate future, I don't expect Mozilla to make a hard commitment to >implement 100% of XForms (or any standard, finished or not). But I would like >to see some "proof of concept" activity, to help spot problems before it's too >late. This sounds right to me -- test the specification with some real code, get some Mozilla community members writing pages to the spec, try to get useful feedback to the wg. I would join roc, as a driver@mozilla.org, in wanting to take a performant, low overhead, smoothly integrated implementation of XForms, provided jkeiser and other Gecko owners and peers agree (cc'ing dbaron, he should be in on this too). Since XHTML 2.0 has been done in Mozilla using only XBL/JS (see http://w3future.com/weblog/gems/xhtml2.xml), why can't XForms be done, as roc suggested, using XBL? Do we need to revive the stalled XBL form control work, to have scriptable interfaces for form submission? Who will own this bug? A bug assigned to nobody@mozilla.org is not going to get re-targeted from the Future. /be
Comment 27•22 years ago
|
||
The initial comment that CC'd me here set the tone badly--I do not think 99% of XForms is bad. It is true that I do not think it is good to implement in its current form. Still, I'd like to try and get some technical problems ironed out. I am working on the spec review, as I said--hopefully I'll have it done and posted to the WG soon. I do not represent all of Mozilla or even all of Netscape. I represent one technical opinion. I work on forms in Mozilla, though, and know them pretty well. I also *created* a number of highly varied web data entry apps for several years before coming to Netscape. I see good things about the spec, and I see bad things. I am late in the process, I know, but I started working with Mozilla less than a year ago so I hope that is forgiveable. Good things: - specifying the oft-repeated "required" property - having a persistent data instance (admittedly I haven't found the "persistent" part there but it could be done) - removing the stupid requirement that form controls be physically contained in forms - XML submission - the spreadsheet idea (unfortunately possibly doomed to a very restricted implementation) Bad things: - the dependence on the bloated XML Schema (who needs 20,000 date types?) - the over-reliance on markup rather than attributes that look to me like markup bloat (makes it tedious to write) - a complete oversaturation of events - the extreme vagueness of definition of dependencies for the "spreadsheet" functionality (this from sicking)--this is crucial for that wonderful feature and the vagueness may belie an essential unimplementability for many XPath functions. Hopefully we can make the spec look better--I'd love to implement the good features, of which there are many. But I don't want to take the bug personally until I'm satisfied it's a good thing for web developers (read: "easy to write"). My opinion.
Comment 28•22 years ago
|
||
Comment 24: > May I remind the Mozilla community that the AOL/Netscape/Sun alliance has > had a representative on the W3C XForms committee for quite some time, and > additionally a representative on the HTML committee, which created the > original requirements for developing XForms? [...] > If the Mozilla community finds that a World-Wide Web Consortium spec's > requirements or goals are not to their liking, perhaps they should have > participated in development of the requirements and specifications. Good point. Why doesn't mozilla.org have a representative on at least the HTML working group?
Comment 29•22 years ago
|
||
Partly because the W3C is a closed club. You can't have a representative on a working group unless your organization is one of the member companies. I suggest the rest of this discussion move to the newsgroups out of this bug...
Comment 30•22 years ago
|
||
No new layout objects should be required to do XForms. All of the proposed widgets can be mapped to existing HTML and XUL objects using XBL/JS/CSS. XML Events are trivial to implement in Mozilla, since you can leverage the XBL code that has a virtually identical syntax for its declarative event handlers. XPath support is a requirement for XSLT, and so it is present in Mozilla. The big gaping hole is the XML schema implementation (and validation). That's the scary part. Anyway, I'd love to see someone mess around with trying to implement this, since it would stress test our extensibility (using XBL to make new tags). I'm happy to supply advice/pointers. I think it's important to ensure that XForms is build- time-configurable like XSLT, MathML and SVG, and then, as long as it doesn't impact perf/footprint etc. when disabled, it should be all right to experiment with.
Comment 31•22 years ago
|
||
As for XML Schema support, please see the XForms Basic conformance level, which does not require an XML Schema processor.
Comment 32•22 years ago
|
||
Yes, you could start with just XForms Basic.
Comment 33•22 years ago
|
||
About two weeks ago, I gave a talk to XML.GOV about XML forms. My stated opinions of XForms concurred with Brendan's opinions in comment 21, and the reactions I heard from XForms proponents were similar to the comments on this bug. Having been involved with the XML-electronic forms business for several years now, let me throw in the industry opinion: 1. People who buy electronic form software want to be able to highly customize the form experience for their users. Just as nobody writes plain-vanilla HTML documents nowadays, nobody (who is willing to pay me money) wants to trust a generic XForms browser to render their form. The first thing people do with HTML is try to override the browser's judgement on font sizes. The same thing will happen with XForms. 2. If more than one person writes an XForms brower, they will not be equivelant. Look at the differences in HTML 4.0 and JS between Mozilla and IE. The industry solution will be to publish forms in some format other than XForms, and then use drivers to render the appropriate XForms variant for each client, jus as high-end web form systems do now. 3. XForms doesn't have key features that key early adopters in government, market researcher, and healthcare need. In particular, the idea of doing validation on the client is totally unacceptable, for various business reasons. That's why we do page-at-a-time HTML forms now, and the same practice will continue with XForms. 4. XForms is really complicated. Whatever happened to KISS? I don't care about high concepts of a superior design process -- I just need something that works. 5. The small companies that write survey software (raosoft, perseus, inquisite, ...) each use every available programming language to write CGI programs that run on every platform. We have enough trouble keeping these synchronized with browser updates as it is, and we fear that a more complicated system like XForms would reduce product lifecycle, increase costs, without offering a clear advantage over HTML forms. Complexity raises the barriers to entry, and gives bigger companies like MS a clear advantage. 6. There are many companies that produce forms software because they choose to solve the problem in different ways that are appropriate for different markets. I fear that XForms is a one-size-fits-none solution. 7. The US DoD, which is a major early adopter, bans the use of Java and JavaScript. That's their reaction to anything which could have a security hole. So your implementation of XForms had better be bulletproof. That said, if there is a demand for it, companies will write software for it. Largely, this is a matter of browsers supporting XForms. But as long as web publishers have to support both HTML and XForms, which version do you think they will prefer? After all, how many times have you turned away from a web site because you didn't want to wait to download the right plugin? How many times is a company willing to lose a sale because of that? I like the idea of trying to bring some innovation to HTML forms. One big thing that's missing is the handling of relational data. Hence the XForms spreadsheet. You could probably do better by extending HTML. MS went and invented HTMLAREA -- why shouldn't Mozilla do some innovation too?
Comment 34•22 years ago
|
||
3. XForms doesn't have key features that key early adopters in government, market researcher, and healthcare need. In particular, the idea of doing validation on the client is totally unacceptable, for various business reasons. That's why we do page-at-a-time HTML forms now, and the same practice will continue with XForms. Client-side validation is a feature that allows early detection of errors before submission, and minimizes postbacks. The existence of a declarative, standards-based validation syntax (XPath, XML Schema types, XML Schema facets) allows the client to perform validation before the data is sent back to the server. Obviously, the server has to validate the data before it accepts it, but just as obviously, if the client can use the same rules to pre-validate it, it's a win for the end user, don't you think? 4. XForms is really complicated. Whatever happened to KISS? I don't care about high concepts of a superior design process -- I just need something that works. Please see XForms Basic which doesn't require full XML Schema and has other simplifications. It's probably the right starting point for most implementations that don't already use XML Schema. 5. The small companies that write survey software (raosoft, perseus, inquisite, ...) each use every available programming language to write CGI programs that run on every platform. We have enough trouble keeping these synchronized with browser updates as it is, and we fear that a more complicated system like XForms would reduce product lifecycle, increase costs, without offering a clear advantage over HTML forms. Complexity raises the barriers to entry, and gives bigger companies like MS a clear advantage. The main advantage XForms brings to such systems is a uniform syntax for data transfer back and forth -- XML instances. The back ends can then use XML tools to validate and operate on the data, and to generate the form documents in the first place. As it is now, the client side contains a hodgepodge of Java, JavaScript, browser vendor extensions, etc, and the server side a hodgepodge of data format conversion tools. The model of submitting a form back as a single XML document surely has clear simplicity advantages, don't you agree? 7. The US DoD, which is a major early adopter, bans the use of Java and JavaScript. That's their reaction to anything which could have a security hole. So your implementation of XForms had better be bulletproof. As XForms is declarative rather than imperative (even the XPath expressions are free of side effects), and the side-effect actions are all defined through the use of events, I suspect that XForms will be much easier to make bulletproof than JavaScript or Java.
Comment 35•22 years ago
|
||
> 1. People who buy electronic form software want to be able to highly > customize the form experience for their users. XForms is styled using CSS. At the moment, CSS allows you a great deal of flexability when styling a document, right down to per-pixel sizing if you really want to. In additon, CSS is understood by many people hence lowering the cost of entry, and with latter versions of CSS, it is certainly becoming even more capabable. > 2. If more than one person writes an XForms brower, they will not be > equivelant. Look at the differences in HTML 4.0 and JS between Mozilla > and IE. From a style POV, using CSS should give an equivalent visual experience in modern browsers. From a functionality POV, if a browser doesn't implement the spec properly, or implement enough of it, the it's not XForms (or XForms Basic). > In particular, the idea of doing validation on the client > is totally unacceptable, for various business reasons. Of course you still do validation on the server side, you never trust data form the client. As klotz pointed out, client side validation greatly improves the user experience by providing immediate feedback, rather than having to wait for the page to reload, and revisit the form, searching through it for the invalid fields. > 5. The small companies that write survey software (raosoft, perseus, > inquisite, ...) each use every available programming language to write > CGI programs that run on every platform. And you still can. XForms allows data to be sumbitted to the server as standard url-encoded data or multipart-encoded data, allowing comanites to continue using the same software they have written already, to keep using the programming lanugage they already using. In additon, data can be submitted as a complete XML document - which is massively useful. > I fear that XForms is a one-size-fits-none solution. Yes, in the exact way HTML is. > 7. The US DoD, which is a major early adopter, bans the use of Java and > JavaScript. So write the server-side code in C# if you really have to. Don't forget to keep on validating data on the server side, just like you do today! > MS went and invented HTMLAREA -- > why shouldn't Mozilla do some innovation too? Heh, you're kidding, right?
Updated•22 years ago
|
Priority: -- → P4
Comment 36•22 years ago
|
||
Well, XForms is now a Candidate recommendation ... will we wait until Microsoft starts deploying XForms, and then we have to play catch up? http://www.w3.org/TR/xforms/ http://www.w3.org/MarkUp/Forms/2003/ImplementationWorkshop/Overview.html
Comment 37•22 years ago
|
||
WRT http://bugzilla.mozilla.org/show_bug.cgi?id=97806#c33 (Shanti Rao) > 1. People who buy electronic form software want to be able to highly customize > the form experience for their users. Just as nobody writes plain-vanilla HTML Yes, styling is important; hence, CSS. > 3. XForms doesn't have key features that key early adopters in government, > market researcher, and healthcare need. In particular, the idea of doing > validation on the client is totally unacceptable, for various business > reasons. That's why we do page-at-a-time HTML forms now, and the same > practice will continue with XForms. I work at one of the largest pharmaceutical companies in the world, and we need XForms. Specifically, what we need from XForms is: * (Most importantly) To get rid of the Javascript dependancy. Javascript accounts for 90% of our headaches in complex forms, and is extremely brittle and unmaintainable. * To get a tighter binding to XML. * Get better datatyping on the client side. * Get client-side validation (business rules). In particular, we have a requirement for off-line forms. We have a specific, common case where the scientist synchronizes her laptop, goes home, and completes some periodic forms that were downloaded onto her system. She doesn't have access to the company network outside of the firewall; she may be offline (overseas, on a plane) while trying to do this work. Client side validation support is a requirement, not an option. * Wizards. This ties in to the previous point, but is pertinent outside of the off-line issue. Page-at-a-time HTML is a terrible user-interface design, and it is extremely complicated to implement a multi-page form that allows bi-directional movement within the form. Wizards, as a paradigm, are much easier to design. The XForm <switch> element is just what we need. > 4. XForms is really complicated. Whatever happened to KISS? I don't care about > high concepts of a superior design process -- I just need something that > works. Complicated for users, or implementors? I haven't done an analysis to see if XForms follows POLS for users, but it is a vast improvement over HTML Forms. > browser updates as it is, and we fear that a more complicated system like > XForms would reduce product lifecycle, increase costs, without offering a > clear advantage over HTML forms. Complexity raises the barriers to entry, and > gives bigger companies like MS a clear advantage. This is fear mongering. The biggest problem with forms, currently, is Javascript. It is extremely (I can't stress "extremely" enough) difficult to implement non-trivial forms that work well in both IE and Mozilla, not to mention Konqueror or other "small" browsers. Reducing the dependancy on Javascript can only help the situation. The actions in XForms are well defined, and there is much less chaos (in the mathematical sense) in XForms than there is in the HTML Forms + Javascript mix. > 7. The US DoD, which is a major early adopter, bans the use of Java and > JavaScript. That's their reaction to anything which could have a security > hole. So your implementation of XForms had better be bulletproof. A strong argument for XForms support. It is *impossible* to implement non-trivial forms without Javascript, and I think I can safely suggest that creating a secure XForms implementation is vastly easier than creating a secure Javascript implementation. My personal beef with XForms is the choice of W3C XML Schema (grumble, grumble), but the other reasonable option, RelaxNG, wouldn't have helped you much since the primary objection to XML Schema in this bug discussion has been supporting the data types, which RelaxNG would be using anyway.
Comment 38•22 years ago
|
||
One of the advantages or XForms that i really like is that the web servers will not need to generate HTML/XHTML using any thechnology like Servlet/JSP, PHP, ASP. The user interface (XHTML) could be served by any HTTP server. Servlet/JSP, PHP, ASP etc. will only be used to generate the data model and to process the form submission. The server load can be decreased because XFORMS XHTML files can be cached if using an external XML model (even if the data model is dynamic)
Comment 39•22 years ago
|
||
Sean Russell has convinced me that XForms could have value in a business process. Considering GSK's needs as Sean describes, the data entry program should also have the ability to load and save form data as XML files, such as an "unsent forms" folder within mail. The form editor is quite tricky. When you write a form, you probably don't want to use the full flexibility of XForms. Instead, you want to write a wizard, and specify validation rules for each section. You also don't want to worry about when you have to call refresh(). And, Glaxo Smith Kline's present software purchasing requirements specify that the form design has to take place over the web and be browser-neutral. So, could one write an XForms editor in XForms, using just a little XUL to show the form in one window and a preview in another? That said, I (Raosoft) and others will probably write web-based XForms editors. This thread is more than a year old, and nobody has started development, and I don't plan to change that state of affairs myself. Is it reasonable to expect Mozilla to have an XForms implementation before 2004? If not, can any of the available XForms plugins be adapted quickly? Or co-opt whatever ActiveX control MS uses? If not, and you feel that the availability of XForms processors will save you money, are you willing to pay for somebody to develop them? If an end user chooses to use a plugin instead of Mozilla's default support, is there a way of ensuring that all these will behave in the same way, lest the old JS incompatibility problems be replaced by XForms incompatibility problems? Would the ability to save XForm XML data as a JavaScript object necessarily create compatibility problems between browsers?
Comment 40•22 years ago
|
||
I wouldn't be astonished to see this start to appear soon from some source or another -- thanks to open source. Depending upon how complete of an implementation you want, I have been told that it shouldn't be too hard to do much of it just by defining it in XBL (behavior language) on top of the widgets of HTML or XUL. There is certainly some interest, and thanks for laying out your case. There are other favorable comments as well. XPath, which is required, is there now. We even have some parts of schema processing there in our SOAP implementation. I have always thought Xforms would combine nicely with SOAP. But you will have to wait for someone else to say when, and you could be right that no contributor will find it compelling enough to do it.
Comment 41•22 years ago
|
||
I have changed my mind--there *are* some things that XForms gives us that would be difficult to put into HTML. It has enough going for it that it's worth implementing (let's see how people use it). Validation will be tighter and easier to read (if you know the new scripting language XPath ;), and can be shared between client and server (BIG plus, something that has always bothered me). Forms can submit XML and essentially do SOAP. You can put UI anywhere now--you're not constrained by the form tag. Arrays of elements will be possible without painful JavaScript or server round-trips. Required elements can be marked as such and displayed in a uniform way by the browser. Yes, there are problems. Syntax gets gross in a few areas. There are too many events. The action model is yet another scripting language waiting to happen. But we're not required to implement everything and if we're vigilant with it we can keep the features out of the next version of the spec (or perhaps even get rid of it when it goes to XForms 1.0 final). I'll take this. I will start implementing a month or two from now when other big stuff is off my plate. It should be a fairly simple task to get a basic implementation up (using XML to vector to HTML form controls). Others interested in doing this between now and whenever I start are perfectly welcome, don't let me stop you :) And let's quit using this for discussing whether to do it. If YOU plan to help you get to bitch or praise all you want.
Assignee: nobody → jkeiser
Comment 42•21 years ago
|
||
When we´ll have this! This is the most important feature today. And... Where is? Please! Please! Do it! It´s time to kill IE!
Comment 43•21 years ago
|
||
> When we´ll have this! When someone has the time to do it. This is a volunteer project, remember? > This is the most important feature today. I strongly disagree. Further, work on the layout engine is focusing on architecture not features right now. You are of course free to implement XForms and the focus on architecture is not such that we would refuse a decent XForms implementation.... Further, I speak for myself; John may have his own opinion as to whether we should be focusing on XForms. All that said, I have no doubt that this would _not_ kill IE in any way, or even make it mildly uncomfortable.
Comment 44•21 years ago
|
||
Perhaps some of the other "projects" interested in xforms can look within their ranks for volunteers. :) For example: Quote from JSR 127 JavaServer Faces http://www.jcp.org/en/jsr/detail?id=127 "Additionally, work continues in the W3C to evolve relavent web technologies (XHTML, XForms) and the expert group will track these efforts to ensure the proposed specification includes enough flexibility to evolve with these technologies as needed."
Comment 45•21 years ago
|
||
I'd like to add to what bz is saying by mentioning that if the architecture of layout is improved, it will make adding features without causing regressions or further convoluted code easier. This is also the case for other parts of Mozilla, including the event system. I agree that features are important, but throwing on new features without occasionally improving the architecture will lead to unmaintainable code.
Comment 46•21 years ago
|
||
How would one volunteer to help implement? Is there a project established for xforms in mozilla? If so where? If not, then why not? It seems there is mounting interest, regardless of dissenting opinions.
Comment 47•21 years ago
|
||
You volunteer by saying so, probably in the netscape.public.mozilla newsgroup (though doing it in this bug is probably sufficient since presumably anyone likely to work on this is cced on the bug).
Comment 48•21 years ago
|
||
What are really cool on XForms? TYPES!!! Until xforms doesnt coded, what do you thing about data types on html forms? Like: <input type="text" dataType="date"> date, month, day, money, string.... or <input type="type" mask="AA-###-###"> thats means like XY-283-393. Heim? What do you thing about?
Comment 49•21 years ago
|
||
XForms includes binary upload from devices, a feature request in bug 46135.
Depends on: input-helper-apps
Priority: P4 → P5
Comment 50•21 years ago
|
||
Huh? I thought XForms was all XML, and XML is all printable characters.
Comment 51•21 years ago
|
||
> and XML is all printable characters.
It's not.
Comment 52•21 years ago
|
||
James, why did you change the priority to P5 at the same time? I don't think that this is appropriate for this issue....
Comment 53•21 years ago
|
||
As someone who served most of 1999 on the XForms working group, watching it evolve from simplicity to absurd bloat, I am certain that P5 for XForms implementation is in the best interests of the Mozilla community. Perhaps a better question would be to ask the author of comment #31 why they wrote that XForms Basic does not require XML Schema support, when the Candidate Recommendation indicates that it does.
Comment 54•21 years ago
|
||
In response to Mr. Salsman's question about XML Schema support in the XForms Candidate Recommendation document, I point to the chapter titled "Conformance Levels" in the XForms CR documment, at <a href="http://www.w3.org/TR/2002/CR- xforms-20021112/slice12.html#conform-levels-basic">http://www.w3.org/TR/2002/CR- xforms-20021112/slice12.html#conform-levels-basic</a> which requires only Schema type support for types defined in the XML Schema spec and the XForms spec. This level of support requires only the ability to associate a data type with a node, using direct string comparison for type names. I.e., <foo xsi:type="xsd:integer">3</foo> or <xforms:bind nodeset="foo" type="xsd:integer" />. I have been looking at Firebird and trying to figure out how to get started. Of course, if the experts in the Mozilla community follow Dave Hyatt's recomendation above and make XML Events (which are just an XML binding to DOM events) and XPath (which is already required for XSLT) available, the rest of XForms can be written in XBL and JavaScript, and I've love to have a hand in helping, but I would really need help from an expert in getting started.
Comment 55•21 years ago
|
||
>> and XML is all printable characters. > >It's not. If you are talking about CDATA, is it unreasonable to omit it from the Mozilla XForms implementation? If not CDATA, can you please send me a link to read more about this?
Updated•21 years ago
|
Whiteboard: DO NOT COMMENT unless you're helping implement this
Comment 56•21 years ago
|
||
James, this is not your bug. Do not change target milestones and priorities on bugs that you do not own. I would expect that a first implementor will implement all the features that can be easily implemented and leave things like input from audio devices for later bugs. Additionally, if someone were to write that feature for XForms they would not necessarily have to implement the accept property, so this bug could also block that bug. Please move meta-discussion of XForms to the newsgroups. This bug is for implementors. By the way, as you may have guessed, my duties have increased to the point where I do not have time for this yet unfortunately; implementors are still needed.
Priority: P5 → P4
Comment 57•21 years ago
|
||
I may have been wrong to change the priority of this bug, but xforms does in fact include the device upload functions provided by bug 46135. I estimate that the number of source code tokens to implement xforms is at least 50 times that required to implement helper input applications. Device upload is therefore an almost entirely proper subset of this bug, and therefore a reasonable dependency, and helper input applications are presently at P5. I have offered a bounty to anyone who wants to attempt bug 46135; email me for details.
Comment 58•21 years ago
|
||
Another reason of the dependency on bug 46135 is that it would be easier to implement helper input applications and then make a new helper input application to process xforms (e.g. using <input type="file" accept="application/xml;xform=sourceurl">) than it would be to implement xforms within gecko. Moreover, accomplishing the first two of those tasks before the third would likely make the total amount of effort for all three tasks a lot less than if the third was attempted before the first two.
Comment 59•21 years ago
|
||
James. Newsgroup. Read the word "should" in http://www.w3.org/TR/2002/CR-xforms-20021112/slice8.html#ui-upload (i.e. not strictly required for an implementation to be marked complete). File your "XForms as helper input app" bug as an enhancement and be clear about how it would work (it's sure not in any spec I know of). And let people implement this bug in peace.
Comment 60•21 years ago
|
||
Okay, but which newsgroup(s) that you read is appropriate for this discussion? What is unclear about the proposal of comment 58? I count at least five examples of helper applications and plug-ins on http://www.w3.org/MarkUp/Forms/#implementations
Comment 61•21 years ago
|
||
The unclear part is just how the data gets from the XForm to the file input (when the data is supposed to be sent directly to the server normally). Just specify how it should happen in the new bug you file, if you feel Xforms-as-helper-input-app is something people will want (I'm not really convinced of that). The helper apps of which you speak are not helper *input* apps in the sense that they don't ask the user for a file that can be sent to the server; so your bug will not help there. XForms can therefore be done with our normal helper apps mechanism, which is sincerely not a bad idea and may already have been done.
Comment 62•21 years ago
|
||
Right. Thank you. Just to be clear, Xforms asks the client browser for an xml file to be sent to the server. Asking Alex Savulov to unfuture bug 46135.
Comment 63•21 years ago
|
||
I'm concerned that XForms might create new security/privacy issues if not implemented correctly.
Comment 64•21 years ago
|
||
People have asked me what kind of security/privacy issues I am concerned about. Well, since its a new standard and is therefore not well tested, I have just your general concerns of security issues involved with sending information to a server (especially possibly personal info), and just wanted to voice those concerns so that security/privacy issues are thoroughly investigated before an implemntation ever being checked in. Its pretty much common sense, but I just wanted to have it here as a reminder.
Comment 65•21 years ago
|
||
What would be involved in implementing this in Mozilla? (Sorry for spamming w/ noobie quest.) The comment from W3C in the XHTML 2.0 specification sparked interest (Section1.1.1): "...thanks to XML and stylesheets, such strict element-wise backwards compatibility is no longer necessary, since an XML-based browser, of which at the time of writing means more than 95% of browsers in use, can process new markup languages without having to be updated. Much of XHTML2 works already in existing browsers..." I was wondering given an XML and a schema (DTD, XSD, RELAXNG), couldn't XForms and XMLEvents be smoothly integrated? Would the current forms engine work, or would this need to be updated? If it needs to be updated, wouldn't it work for older HTML3/4 forms and XForms? (Sorry if this is newbie spam. :-/ )
Comment 66•21 years ago
|
||
XForms has now reached Candidate Recommendation Status. http://www.w3.org/TR/2003/PR-xforms-20030801/
Comment 67•21 years ago
|
||
Proposed Recommendation this should be. :o)
Comment 68•21 years ago
|
||
Yes, I would like to see xforms implemented, as I see this tool very useful in the financial world.
Comment 69•21 years ago
|
||
From : http://www.w3.org/MarkUp/Forms/ XForms 1.0 now a Proposed Recommendation. The public is invited to send comments about this document directly to www-forms-editor@w3.org (archives).
Comment 70•21 years ago
|
||
XForms 1.0 is now a W3C Recommendation: http://www.w3.org/TR/2003/REC-xforms-20031014/
Comment 71•21 years ago
|
||
See http://lists.w3.org/Archives/Public/www-forms-editor/2003Sep/0006.html and http://lists.w3.org/Archives/Public/www-forms-editor/2003Sep/0017.html -- XForms is not likely to replace HTML forms. FYI: Any Mozilla XForms implementation may be an optional extension. The forthcoming roadmap update will start to make clear the Mozilla standards policy by which configurables are included in the default GRE. /be
Comment 72•21 years ago
|
||
> XForms is not likely to replace HTML forms.
XForms certainly won't have a much of chance of being widely accepted if none of
the major browsers implement it. You are basically saying they won't implement
it, so Mozilla won't bother much with it either.
How can the web move forward with this sort of attitude? Incredible!
Give up now, go home, buy your products off-the-shelf.
Comment 73•21 years ago
|
||
Whether implementing XForms is "moving forward" is debatable, but that debate doesn't belong here. However, implementing helper input applications (bug 46135) would make it easy to seamlessly integrate any number of modular XForms implementations with Mozilla, along with everyone's preferred text editor as an alternative to TEXTAREA, graphical and sound editors, scanner interfaces, etc. All without any more web server support than existing pervasive multipart/form-data parsers (i.e., XML parsing for XForms would be convieniently removed to the server application or XForms library and does not become the added responsibility of httpd.) The fact that, currently, helper applications can be used to display output data of any type but input options are severely limited to HTML forms (the most sophisticated being TEXTAREA and raw file upload) is a glaring lack of symmetry in the interactivity of today's web. It was NOT supposed to be this way, and in fact was designed specifically around this asymmetry by Dave Raggett and Tim Berners-Lee almost exactly ten years ago; please see: http://bovik.org/devup/tbl-devup.txt Anyone who wants to see XForms should support the superset of input helper applications.
Comment 74•21 years ago
|
||
The arguments against XForms in Mozilla are numerous and all given in the posts Brendan mentioned in comment 71. Please read those two posts carefully (the whole way through) to understand our position. (Replies to those posts belong in the same mailing lists as the posts themselves.) There exist work-in-progress proposals for developing HTML forms further, in a backwards-compatible manner, for example the Opera-sponsored "XHTML Module: XForms Basic": http://www.damowmow.com/temp/hfp.html Comments on that incomplete proposed draft specification are welcome, please send them to me at ian@hixie.ch.
Comment 75•21 years ago
|
||
I read the detailed critiques in comment 71. Notwithstanding their many apparently-valid points (on which I confess I'm still unsure), there is a counterbalancing body of enthusiasm for XForms - see http://www.w3.org/2003/10/xforms-testimonial Maybe XForms is imperfect but it looks like it will be significant nonetheless. Therefore the argument for its inclusion in Mozilla seems a good one.
Comment 76•21 years ago
|
||
Why would anybody want to use/implement that Opera stuff ("XHTML Module: XForms Basic")? If you decided to use it in your form it would probably be necessary to create a pure HTML/JavaScript version for backward compatibility anyway. Opera is a small company but I would still call this FUD. Just look at http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html it's so beautiful.
> If you decided to use it in your form it would probably be necessary
> to create a pure HTML/JavaScript version for backward compatibility anyway.
I don't see how that's a disadvantage relative to XForms.
Updated•21 years ago
|
QA Contact: vladimire → ian
Comment 78•21 years ago
|
||
> I read the detailed critiques in comment 71. Notwithstanding their many > apparently-valid points (on which I confess I'm still unsure), there is a > counterbalancing body of enthusiasm for XForms - see > http://www.w3.org/2003/10/xforms-testimonial Of course there is a big difference between people who are generically enthusiastic about something, and people who have raised specific issues that have not been resolved. > Maybe XForms is imperfect but it looks like it will be significant > nonetheless. Therefore the argument for its inclusion in Mozilla seems a good > one. PDF and Flash are significant too, but we're not implementing those natively either. XForms simply isn't appropriate for Mozilla, as described in the posts in comment 71. > Why would anybody want to use/implement that Opera stuff ("XHTML Module: > XForms Basic")? This is just a draft at the moment. We hope to have it go through normal W3C process and become a REC just like XForms. Why would anyone want to use/implement that W3C stuff ("XForms")? > If you decided to use it in your form it would probably be necessary > to create a pure HTML/JavaScript version for backward compatibility anyway. So just like XForms then? I don't understand your point. > Just look at http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html > it's so beautiful. I'm intimately familiar with that document, as well as the XForms spec, and have even got a copy of the XForms book by Micah Dubinko on my desk right next to me. "Beautiful" is far from what I would call XForms, for all the reasons described in the aforementoned posts.
Comment 79•21 years ago
|
||
I am very disappointed by the anti-XForms arguments presented here. The question as to whether XForms should be included in mozilla should turn on the analysis of two questions: (1) is it consistent with Mozilla's mission and (2) is there user demand. As to the latter, 415 votes (as of 2003-10-20) seems like a pretty explicit affirmative answer. W3C working groups aren't generally formed unless people want and need a solution. As to mission, we should examine the mission statement of Mozilla. Mozilla aspires to be a browser "designed for standards-compliance, performance and portability". Well, like it or not, XForms has just been adopted as the standard for representing advanced forms in a web context. The criticisms lobbed against XForms, regardless of merit, can be assumed to have been vetted in the working group and rejected. Upon release of the W3C recommendation, those who wish to persue the mozilla mission of agressive standards compliance should be asking "how" and "when", not "if". In particular, knockers of XForms in Mozilla are trying to get a lot of milage out of the criticism advanced by Apple and Opera along the lines of "XForms is not likely to replace HTML forms". This is true but highly misleading, since XForms is designed to meet advanced forms needs, while HTML forms can and will remain in place to meet the basic form handling needs. Apple and Opera even recognize this in their position when their representative writes "In summary, we don't have anything against XForms 1.0 as long as the recommendation clearly states that it is not a *replacement* for HTML forms, but that XForms 1.0 is a language targetted at higher level Web applications using complex forms." (from the second letter cited in comment 71 above). The counterclaims listed by Apple and Opera in the first post cited by comment 71 above, aside from being post-game bickering, fall into a few main groups: A) XForms is more complicated than HTML forms for doing task X -- Yes. Wouldn't you expect ADVANCED Forms to be a little more involved than their simpler predecesors. That's exactly what was desired: a little more power at the cost of a little more syntax. B) XForms doesn't really solve problem X or problem X isn't a problem any more. So what. Are they really this desparate to lengthen their list? C) XForms depends on too many other specs, such as namespaces, XML Schema, XPath, XML Events, DOM Events, DOM Core, CSS, stylesheet linking, and a host language (XHTML or SVG) -- Again, it's ADVANCED forms, so it should be expected to touch a lot of related technologies. Certainly none of the other specs should scare anybody here. Mozilla's mission is to be standards compliant, so these standards are all blocking and tackling. There is a surprisingly long list of working implementations of XForms, so I just don't buy that this should be a show stopper. I hope that mozilla will have the vision to (1) listen to the 415 users who are voting for this bug who aren't interested in bickering about whether XForms is perfect and (2) reaffirm their commitment to the stated Mozilla mission by incorporating relevent new web standards into the Mozilla core as those standards become stable.
Comment 80•21 years ago
|
||
Bryan Taylor: your lengthy advocacy statement does not belong here. The main argument is essentially an argument from authority (if the w3c has raised XForms to REC status, it must be good), which is a fallacy. The secondary point (that ADVANCED forms should be expected to be complex, have many dependencies, and be harder to use) is weak. Why is that necessarily so? But the main reason I'm writing (having commented briefly recently only to say that XForms may some day be an optional extension in Mozilla, but is not likely to be built in by default, for the reasons given in the Apple and Opera joint statement) is to say that 415 people clamoring for anything in Mozilla will do *nothing* to get that thing implemented. Until a volunteer or paid contributor who can successfully implement and integrate XForms steps up, it's not going into Mozilla. So noise in this bug doesn't help, and probably hurts. Note also that having an implementation in hand, even if integrated, and even if the format it supports is wanted by hundreds of Mozilla fans, doesn't guarantee inclusion (see the MNG controversy). Mozilla is not all things to all people, and we must trade features and footprint (and other integration costs) off against one another. The prevailing problem on the web today, unaddressed by most W3C work, is that the IE monopoly has frozen progress. The client architecture, while annoyingly complex due to unstandardized quirks modes needed to handle real-world content, is stagnant. Big (hard to implement consistently and completely), new (no content deployed widely on websites for years to come) standards will not help change this situation for the better. I sincerely believe that the web world would be a better place if fewer large/second-system-syndrome XML-based de-jure standards were promulgated, and more evolutionary steps were taken based on the existing standards that people actually use. For one thing, the odds that any two or more of {IE, Opera, Mozilla, Safari} would implement the new standards consistently would be much higher than they are now (nearly 0). Let's take the advocacy comments to the newsgroup (news://news.mozilla.org/netscape.public.mozilla.layout). The status whiteboard still applies. /be
Comment 81•21 years ago
|
||
>[from #80] Bryan Taylor: your lengthy advocacy statement does not belong here.
Brendan Eich: With all due respect, neither does your rather lengthy anti-
advocacy statement. I agree whole-heartedly with the statement at the end of
your post- the advocacy comments enlong in the newsgroups.
Is there any way to limit the comments here to updates on the status of this
issue? I am (somewhat) loathe to unsubscribe to this issue, because I am
interested in keeping abreast of its status (I work for a company that
produces e-forms software so this issue is relevant to my job).
I am not, however, interested in hearing a rehash of many of the same issues
that were discussed during the development of the XForms spec. This is not to
say that the issues raised are not valid, just that this isn't the place to
debate them.
Comment 82•21 years ago
|
||
> Brendan Eich: With all due respect, neither does your rather lengthy anti-
> advocacy statement.
Then nothing can be done for all of us who want no more useless advocacy
comments except to ignore them.
However, my posts are more than admonishments not to advocate in bugs. I seek
to make it clear that mozilla.org is not bound to implement anything, even if it
becomes a w3c REC. I also hope to make clear why that is the case.
Finally, I am one of the people ultimately responsible for mozilla.org's
reputation, its claim to success or failure. So I have to be able to make
things stick, so to speak. When it comes to degrading the bug system, that
means I and a few others can decide to restrict abusers' access, after first
(and second, and probably third) reminding them not to abuse the bug system.
I'm now done giving reminders; you won't hear from me in this bug again except
for technical comments on implementation and configuration issues.
/be
Comment 83•21 years ago
|
||
Jesus ****! (I.Welsh, "Trainspotting") then why here keyword "helpwanted"?.. you need help where you don`t want work?.. how somebody can help if you not want work?... maybe somebody must do just ALL job instead you?.. in this case this is not help... if mozilla want fight with IE on enterprise intranet field - it MUST implement XForms... or it prefer to be just "street html web browser"?.. "hello, my name is Jane, i like party and pink color"... ok... if you really want implement xform then i can really help you... in other case - we can just ban each other...
Comment 84•21 years ago
|
||
I totally agree with some points, and I totally disagree with other points, however, I will not express any as I feel this is appropriate for: news://news.mozilla.org/netscape.public.mozilla.layout Please have the respect and maturity to place further advocacy comments in the above URL, and leave this for technical related discussion ONLY when we get to that point. Adding more pro/anti-XForms serves no purpose in the scope of this bug.
Comment 85•21 years ago
|
||
Ignoring the question of whether or not XForms *should* be implemented in Mozilla, from a technical perspective, Mozilla is quite capable of implementing support for XForms. Opera and Safari do not have support for tag extension technologies like HTCs (WinIE) or XBL (Mozilla). IMO XBL significantly lowers the implementation barrier for XForms in Mozilla.
Comment 86•21 years ago
|
||
The primary problem with implementing XForms in Mozilla as far as I can tell is that we don't support arbitrary Node-to-Schema-Type validation (see bug 223097). Our lack of XML Events support (bug 164482) is also a blocker.
Depends on: xmlschema
Comment 87•21 years ago
|
||
Comments 30, 31, and 32 address the XML Schema issue. There is no need to implement arbitrary XML Schema type validation, just a basic list of types, whose names can be determined with string comparisons. Comment 30 also states that XML Events should be "trivial" to implement, but it certainly does belong as a prereq for this bug.
Comment 88•21 years ago
|
||
Yes, XML events should be quite easy to implement, since conceptually they are identical to XBL handlers. The only real difference is that in XBL the handler DOM nodes are thrown away in order to compress footprint, and a more compact structure is built for the individual handlers. I suppose you couldn't get away with this when implementing XML events, but maybe as a first cut it would be ok. I stand by my original statements that XForms Basic would be quite easy to implement in Mozilla, since Mozilla has a tag extension technology (XBL) that can easily be used to map the user interface of XForms to the appropriate widgets. Ignoring the issue of whether or not XForms *should* be implemented in Mozilla, it's quite clear that the real problem here is that no engineers are stepping up to the plate to implement it. Mozilla at this point consists almost entirely of volunteer programmers now, and if the volunteers aren't there, the feature isn't going to get developed.
Comment 89•21 years ago
|
||
Ah, true, if we were willing to settle for XForms Basic, we would not need to do real XML Schema comparisons, just QName comparisons. (Note: That's not as easy as string comparisons, and if you think it is, you don't understand XForms. But it isn't that much more complicated.) This bug is therefore currently blocked by lack of XML Events support.
Comment 90•21 years ago
|
||
I won't comment on the 'advocacy' question since I am obviously in favour of XForms. So, if I can take for granted that there is a desire (at least by some) to see XForms in Mozilla, then I'd like to add some comments that relate to *implementation*. One quick point first though - just because a browser can attach functionality to nodes (XBL, HTC, etc.) doesn't make the implementation of XForms 'easy'. It gives you a great mechanism to bind in your components, but you still need those components. Anyway - a little background. We've spent the last two years developing a COM- based XForms processor, formsPlayer [1]. The processor has been architected in such a way that the components can be all client-side, all server-side or distibuted. We have completed an IE6 version, which was one of the two 'first' implementations that helped XForms advance to PR by proving it was possible to implement 100% of the XForms standard. We are now in the process of using these components in different situations, namely Pocket PC and server-side versions. But it goes without saying that on our "To Do" list is to use the components in Mozilla (not least because of the power of Gecko). In my view it would be quicker for us 'XForms experts' to move formsPlayer to Mozilla, than it would be for 'Mozilla experts' to add an XForms processor. (Of course we can debate that ;-)) But there is no reason why we couldn't meet in the middle, hence this post. My questions mainly relate to what form an XForms processor would take. I'm aware of the plug-in facilities in Mozilla and related browsers, so would that be the preferred method? If that was the case then I would assume that with a little help from us, a 'Mozilla expert' could wrap our COM objects and get going quite quickly. Would we need to convert our COM objects to the Mozilla COM format, or are stubs used to map across? Putting the COM question to one side, I still don't think we would get away without modifying *anything* in Mozilla, but at the moment the main thing I can see is that extra properties would need adding to CSS, which looks pretty straightforward. Does that seem right, or are there other areas that people can see might need addressing? The other route to integrating an XForms processor would be for us to take our C++ code and port it directly into Mozilla. That would obviously be a much bigger job, but the obvious advantage would be that we would then have XForms support on any platform that Mozilla supports. My main problem with this route though - even putting aside the obvious question of resources, IPR, and so on - is exactly how to go about getting the code in, in relation to other Mozilla projects. There are quite a few things that would need to change if we were to 'harmonise' XForms into Mozilla; people have already mentioned DOM 2 Events, but there are some others. It therefore seems to me that this is not something that could be developed in isolation, but would need careful coordination with other areas. Obviously at this stage there are more questions than answers, I'm afraid, but I'd be interested to know from the 'Mozilla experts' what the integration options are, given that we already have a full C++ XForms processor implemented, and that this processor is already organised as a series of COM objects. [1] http://www.formsPlayer.com/
Comment 91•21 years ago
|
||
Implementing XForms in Mozilla should be done without duplicating features that are generic (e.g. the XML Events part should just be generic XML Events, the XPath part should just be generic XPath, the submission part should just be generic submission, etc). I do not know (since I haven't seen the code) how well the forms player code would merge in with Mozilla. As far as I can tell bug 164482, bug 223097, and an as-yet unfiled bug covering generic submission (so that XForms can submit XML forms without duplicating any of our form submission code) are the only real blockers.
Comment 92•21 years ago
|
||
AFAIK, now we can use XPath in JavaScript code to select a node set from document. Maybe, this will be helpful.
Comment 93•21 years ago
|
||
Comment 91: > Implementing XForms in Mozilla should be done without duplicating > features that are generic (e.g. the XML Events part should just be > generic XML Events, the XPath part should just be generic XPath, > the submission part should just be generic submission, etc). Of course. formsPlayer has all of these as separate modules and it's certainly possible to replace one component with another. For example, although we use the Microsoft XML Parser as our 'XML source', we have written a COM layer that implements DOM 3 XPath. This means that our interfaces to the XML DOM are 'standard' and would make swapping out parsers, XPath processors, and so on, pretty straightforward. To make this easier, we have also implemented some of the DOM 3 Implementation Registry interfaces. > I do not know (since I haven't seen the code) how well > the forms player code would merge in with Mozilla. With respect, I could just as easily say the same thing! I haven't had a chance to look at the Mozilla code base much, so I don't know how long it will take people to put in the 'other standards' like schema validation, DOM 2 Events, XML posting, DOM 3 XPath, XPath extension functions, and so on, that are needed as the foundation for a full XForms implementation. Anyway, some of these modules we already have; some we have created ourselves - like DOM 2 Events - and some of them rely on the underlying parser - such as schema validation. But given your comments and a sense of what is still to be done, it looks like we might be best just treating our module as a self- contained object for now, and just building an add-on. Does that seem a realistic approach?
Comment 94•21 years ago
|
||
My understanding is that mozilla.org very much wish to avoid code duplication, as Mozilla is fat enough already (to put it mildly). So no, I don't think it would be a good idea to simply lump existing code and hook it in without actually making the code a real part of Gecko. However, it would be an interesting extension to make available; see http://www.mozdev.org/. > I don't know how long it will take people to put in the 'other standards' > like schema validation, DOM 2 Events, XML posting, DOM 3 XPath, XPath > extension functions, and so on, that are needed as the foundation for a full > XForms implementation. DOM2 Events and DOM3 XPath are done, I think. XPath extensions are not on the cards yet (that would be part of this bug). Schema validation and XML Events are not done yet but are being considered, I think. A generic posting mechanism (preferably one that can be hooked into from JS) is another one of the prerequisites for this bug that isn't done yet. (BTW, doesn't XForms require a lot of specs? Jeez.)
Comment 95•20 years ago
|
||
If I am not on the CC list for this bug, why do I get emails whenever it's updated?
Comment 96•20 years ago
|
||
you're one of the 500 people who voted for this bug. so your comment (as well as and this comment) was sent to most of the (105) people on the cc list in addition to most of the (500) people who voted for this bug, and it may have been sent to up to 591 people. http://bugzilla.mozilla.org/userprefs.cgi?tab=email has a column for voter, if you don't like getting certain mail types for voting then remove some of the checks. note that http://bugzilla.mozilla.org/votehelp.html (which is what "Votes" links to) clearly says "You will automatically get email notifying you of any changes that occur on bugs you vote for." i'm sorry for commenting and sending bugmail to the potentially 591 people who are somehow connected to this bug.
Comment 97•20 years ago
|
||
> IMO XBL significantly lowers the implementation barrier for XForms in Mozilla.
My understanding is that we never competely figured out (or fixed) the
performance problems in XBLFC (XBL-based html form controls). That's why they
were never turned on by default. So, I'm not sure that the implementation
barrier is truly lowered unless it's going to be for an implementation that's
for a smaller audience, and not part of a default build.
While I agree that an XBL implementation probably won't be as performant as a C++ one I still think that's the way to go. First off, spending mant manmonths on something that we have no idea how much it will be used sounds like a bad decision to me. XForms has not recieved a warm welcome in the browser community and technologies that are mozilla-only tend to not be warmly welcomed by the webdeveloper community. Also, XBL does not neccesarily mean bad performance. After all, most of XUL is implemented in XBL. Once we have a XBL implementation, and it turns out that it gets utilized a lot, and if it turns out to have performance problem, then we should look into fixing that. Either by fixing XBL, or by writing a C++ implementation. Hopefully the former.
Comment 99•20 years ago
|
||
Aaron: there's no need to revive XBL form controls or optimize prematurely. We use XBL for all sorts of chrome UI widgets. Unless XForms must scale to slashdot or hotmail scale HTML form edge-cases, right away or even soon, we can use XBL and optimize as we go. "Premature optimization is the root of all evil" - Dijkstra, IIRC. /be
Comment 100•20 years ago
|
||
I readed at http://www.mozilla.org/events/dev-day-2004/roadmap/ that someone is working on this, who is that person? or he or she can contact me if preferred, I just want to offer my help. I have been learning XBL recently trying to implement parts of XForms. John Keiser has this bug assigned since 2002, is him the person working on it?
Comment 101•20 years ago
|
||
(In reply to comment #100) > I readed at http://www.mozilla.org/events/dev-day-2004/roadmap/ that someone is > working on this, who is that person? or he or she can contact me if preferred, I > just want to offer my help. I have been learning XBL recently trying to > implement parts of XForms. John Keiser has this bug assigned since 2002, is him > the person working on it? See the XForms project page (http://www.mozilla.org/projects/xforms) and the corresponding announcement (http://www.mozilla.org/press/mozilla-2004-08-10.html).
Comment 102•20 years ago
|
||
Reassigning to default owner. When the IBM developers get a chance they should take this bug.
Assignee: john → form-submission
QA Contact: ian
Comment 103•20 years ago
|
||
Setting QA contact back to Hixie (I had no other way to set to default owner)
QA Contact: ian
Comment 104•20 years ago
|
||
*** Bug 260390 has been marked as a duplicate of this bug. ***
Comment 105•20 years ago
|
||
I see no mentioning of it, but has someone considered using X Smile to do parts of the hard work. ( http://www.x-smiles.org/ and http://sourceforge.net/projects/x-smiles/ ). I'm not sure how mature it is (they say beta on SF, but there are no files there), if the people involved would like to share, not even sure about the licence. The whole thing is written in Java, so it might help ease implementation. Someone might even consider an Extention. Ideas/suggestions ?
Comment 106•20 years ago
|
||
the license for x-smiles is similar to apache license is very short and don't say in any place that the modification of source code or extarcting some parts of are forbidden here is the license for x-smiles http://www.x-smiles.org/licenses/LICENCE_XSMILES
Using x-smiles is impossible since it's written in java and mozilla in C++. This would make it impossible to have xforms elements inside xhtml or xul pages.
Comment 108•20 years ago
|
||
i searched in whole bugzilla site and i founs some bugs that maybe are related to this i found more but i suppose that the list displayed here are more related with this bug that tha all others that i found . anyone can verify if they are related is somehow with this bug ? the list of bugs are: 277929 Error in XForms XPath parser (maybe is related) 277318 implement XForms hint, help and alert elements (related) 273428 xforms input element checkbox behavior w.r.t. instance data (maybe related) 263086 Implement XForms submission (related with target milestone mozilla1.8beta) 275453 Implement <xforms:upload> (i supose that it's related , currently with a released patch) 258472 Add the XPath functions needed for XForms (i can't understand if it's related or not)
Comment 109•20 years ago
|
||
(In reply to comment #108) > i searched in whole bugzilla site and i founs some bugs that maybe are related > to this i found more but i suppose that the list displayed here are more related > with this bug that tha all others that i found . anyone can verify if they are > related is somehow with this bug ? > > the list of bugs are: > 277929 Error in XForms XPath parser (maybe is related) > 277318 implement XForms hint, help and alert elements (related) > 273428 xforms input element checkbox behavior w.r.t. instance data (maybe related) > 263086 Implement XForms submission (related with target milestone mozilla1.8beta) > 275453 Implement <xforms:upload> (i supose that it's related , currently with a > released patch) > 258472 Add the XPath functions needed for XForms (i can't understand if it's > related or not) > As mentioned in comment #101, there is work being done to implement XForms in Mozilla. You'll also notice in bugzilla that there is a XForms component and as you've seen, there are bugs open against the implementation. We are doing our own implementation in Mozilla and not borrowing code from any other implementation. We are leveraging Mozilla's XTF to make an XForms extension to Mozilla.
Updated•18 years ago
|
Assignee: form-submission → aaronr
Component: HTML: Form Submission → XForms
Updated•18 years ago
|
Assignee: aaronr → xforms
Updated•17 years ago
|
Assignee: xforms → nobody
QA Contact: ian → xforms
Comment 110•15 years ago
|
||
Extra comment on security: Xforms with digest function [http://www.w3.org/TR/xforms11/#fn-digest] will make easier to have login/password which are not vulnerable to form-grabbing which is used by all malware today (you grab login/password before they get in https tunnel, like with extension live http headers). Today, the only way to solve this, is java/javascript virtual keyboard with, behind, a hash function.
Comment 111•11 years ago
|
||
I’m guessing this is a WONTFIX now that they’ve been marked as obsolete on MDN? https://developer.mozilla.org/en/docs/XForms
Comment 112•11 years ago
|
||
Indeed, we would not accept an implementation even if somebody wrote it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•