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)

enhancement

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/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Setting up dependencies.
Depends on: 57209
Depends on: 58317
No longer depends on: 58317
Over to eric
Assignee: rods → evaughan
spam - adding self to cclist
This is for you buddy.
Assignee: evaughan → hyatt
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
removing myself from the cc list
Alias: xforms
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.
Reflecting reality.
Assignee: hyatt → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: mozilla1.2alpha → Future
*** Bug 162200 has been marked as a duplicate of this bug. ***
Blocks: xhtml2
Obviously we can't really do this until XForms becomes a Recommendation.  
Currently it's a Working Draft...
Blocks: majorbugs
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...
Yes, but it is the last working draft. XForms is a huge spec and it will take
some time to finish.
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.
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.
> 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".
adding dependency on XML Events
Depends on: XMLEvents
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.
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.
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.
Why not implement XFDL instead of XForms ;-)

At least it's a working one. And there is at least one implementation to follow...
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?
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 :-).)
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.
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.
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.
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
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 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?
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...
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.
As for XML Schema support, please see the XForms Basic conformance level, which
does not require an XML Schema processor.
Yes, you could start with just XForms Basic.
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?
    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.
> 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?
Priority: -- → P4
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
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.
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)
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?
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.
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
No longer depends on: 57209
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!
> 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.
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." 


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.
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.
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).
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?
XForms includes binary upload from devices, a feature request in bug 46135.
Depends on: input-helper-apps
Priority: P4 → P5
Huh?  I thought XForms was all XML, and XML is all printable characters.
> and XML is all printable characters.

It's not.

James, why did you change the priority to P5 at the same time? I don't think
that this is appropriate for this issue....
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.
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.
>> 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?
Whiteboard: DO NOT COMMENT unless you're helping implement this
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
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.
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.
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.
Depends on: 83749
No longer depends on: input-helper-apps
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
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.
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.
I'm concerned that XForms might create new security/privacy issues if not 
implemented correctly.
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.
Keywords: intl
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. :-/ )
XForms has now reached Candidate Recommendation Status.
http://www.w3.org/TR/2003/PR-xforms-20030801/
Proposed Recommendation this should be. :o)
Yes, I would like to see xforms implemented, as I see this tool very useful in
the financial world.
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).

XForms 1.0 is now a W3C Recommendation:

http://www.w3.org/TR/2003/REC-xforms-20031014/
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
> 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.
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.
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.
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.
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.
QA Contact: vladimire → ian
> 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.
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. 
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
>[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.
> 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
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...
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.
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.
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
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.
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.
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.
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/
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.
AFAIK, now we can use XPath in JavaScript code to select a node set from
document. Maybe, this will be helpful.
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?
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.)
If I am not on the CC list for this bug, why do I get emails whenever it's updated?
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.
> 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.
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
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?
(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).
Reassigning to default owner.  When the IBM developers get a chance they should
take this bug.
Assignee: john → form-submission
QA Contact: ian
Setting QA contact back to Hixie (I had no other way to set to default owner)
QA Contact: ian
*** Bug 260390 has been marked as a duplicate of this bug. ***
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 ?
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.
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)
(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.
Depends on: 263086
No longer blocks: majorbugs
Assignee: form-submission → aaronr
Component: HTML: Form Submission → XForms
Assignee: aaronr → xforms
Assignee: xforms → nobody
QA Contact: ian → xforms
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.
I’m guessing this is a WONTFIX now that they’ve been marked as obsolete on MDN? https://developer.mozilla.org/en/docs/XForms
Indeed, we would not accept an implementation even if somebody wrote it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.