Ian Hickson <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > This post represents only my personal opinion. > > On Wed, 27 Apr 2004, Bryan W. Taylor wrote: > > > > [XForms] is aimed at addressing the gap between thin HTML forms and fat > > GUI apps. > > It's not clear that this aim hits target, though. It appears to be > suitable for people writing professional form-based data entry and > workflow systems, as in tax reports, or insurance forms.
... or forms for human resources, financials, order managment, inventory, customer relationship managment, engineering change orders, materials logistics, or any other type of business form that the large IT departments of every company in the world spend most of their time developing. If this isn't enough, you could also use XForms to configure any desktop app that uses XML config files, and do so remotely with close interlinking of help docs and howtos. > It doesn't seem to be really suitable for your typical graphical (Web) > application. Can you elaborate? How can adding capabilites with a richer event model, better separation of structure, logic, and layout, and support for XML instance data result in a loss of suitability for the typical web app? > > I believe that XForms could actually be the kind of jolt that would > > allow Mozilla to get penetration onto some corporate desktops. > > It is true that there are certain (relatively small) segments of the Web > browsing population that would probably use Mozilla if it supported > XForms. Seen in the context of the ~0.6 billion Web users, though, this is > a very small market. The majority of programmers in the world are employed in corporate IT shops managing form based data entry, workflow, and decision support for the types enterprise systems I listed above. The 0.6 billion web users you describe will for the most part, go where these developers take them, at least at work. At home, I expect they'll do what they are familiar with from work. > > Let me explain why an XML bound data form is so valuable to > > corporations. Especially when multiple databases or business services > > are being fed, it is very desirable to have the data in an XML format. > > Why? XML is the only standard for defining and representing platform indepent data that has widespread support across programming languages for common data-centric operations like parsing, validation, transformation, extraction, messaging, and marshalling. By using XML for data interchange systems integration tasks can fully decouple architecture, platform, and implmentation choices on each side. > > Hopefully I don't have to explain why XML makes enterprise application > > integration easier. > > It is not at all clear to me that it does, so yes, please do. It really is as simple as what I said above. Here's an article which is typical that describes how XML is used for data interchange in the healthcare industry: http://www.softwareag.com/xml/library/schroeter_healthcare.htm Here's an Oracle page describing typical use cases. This is a good description of the status quo with a typical technology stack. Changing to MS or IBM or J2EE or open source solutions really only changes the product names. http://otn.oracle.com/tech/xml/htdocs/xml_data_exchange.htm Numerous examples of business to business data interchange formats can be found at OASIS, xml.org, and some of the format standards groups, like ebXML. Here's an article describing the use of ebXML formats in the auto industry: http://www.informationweek.com/shared/printableArticle.jhtml?articleID=18201098 One point to keep in mind is that data exchange over department boundaries is just as hard as across business boundaries. It would be nice if CIO's would force internal architecture standards, but it doesn't seem to happen much. I'll continue the discusion and respond to the rest of your points is a separate post as soon as I have time. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
