W3C home > Mailing lists > Public > www-forms@w3.org > February 2003

RE: Question

From: John Boyer <JBoyer@PureEdge.com>
Date: Thu, 20 Feb 2003 13:14:12 -0800
Message-ID: <7874BFCCD289A645B5CE3935769F0B52452A6F@tigger.pureedge.com>
To: "Doug Mcneil" <mcneil@nortelnetworks.com>, <www-forms@w3.org>
Hi Doug,
Actually, yet another option exists.  Enterprise deployment of a custom plugin is only problematic if the enterprise has not invested in fairly inexpensive and straightforward deployment software.  Sometimes this software is sold along with the plugin itself by the plugin manufacturer.
The natural case in point that I can draw upon is the PureEdge browser plugin for its secure XML forms language.  Certainly, you can get an installer for it that can be run on a person-by-person basis, but you can also get the so-called 'Internet Deployment System', which is a server-side system that manages the deployment and upgrade of client-side software packages.
This type of software is becoming increasingly commonplace as it makes short work of deploying consistent client-side systems, including plugins.  It's only people who don't know about these systems that still insist on the reduced functionality of server-only solutions.
John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.


-----Original Message-----
From: Doug Mcneil [mailto:mcneil@nortelnetworks.com]
Sent: Thursday, February 20, 2003 6:57 AM
To: www-forms@w3.org
Subject: RE: Question


I think, as usual, that the reality lies somewhere in between (how is that for wishy-washy -:). My experience is that a limited number of industry standard Plug-ins (de-facto rarely de-jure) get adopted by most IT departments. Either because they have demonstrated valuable functionality (PDF, Flash?) or the user community vociperously complains if denied access (RealAudio). These are typically bundled into the supported application suite tested and maintained by IT. Getting another Plug-in into the pipeline is a difficult and time consuming process. Even an upgrade to an existing Plug-in is problematical.

Failing rapid introduction of XForms by Microsoft into IE I see two alternatives: 1) Trogan Horse Plug-in - either Adobe or Macro Media release  XForms versions of Acrobat or Flash respectively; or 2) server-side XForms.

Neither of these alternatives provide seemless XForms support. The third alternative although unlikely IMHO is the dedicated XForms Plug-in. Such Plug-ins will have limited acceptance in limited deployments. The major sources will be the open-source community, vendors who attach their star to standards (AOBM) and the odd large corporation with CIO willing to go out on a limb.

I have a decision along these lines to make in the next six months. Although I do not like the thought of living with the consequences I lean towards the server-side.


Doug McNeil 
Product Supportability 
Nortel Networks 

-----Original Message----- 
From: Mark Birbeck [ mailto:Mark.Birbeck@x-port.net] 
Sent: Thursday, February 20, 2003 9:21 AM 
To: 'Sikora, Gary'; www-forms@w3.org 
Subject: RE: Question 


> Yes, all of this can be accomplished with plug-ins.  However, many 
> corporations and Federal agencies do not allow their staff to freely 
> download plug-ins because of security and platform compatibility reasons 
> - argh, that system administrator. 

I think there are two different models here. The 'old' model is what you are 
referring to, where developers have added some clever functionality to their 
web pages with ActiveX or whatever, and as you rightly say these downloads 
would never get past most corporate firewalls. 

But the 'new' model is that there are a small and manageable number of 
quality plug-ins that meet specific needs, and given that these plug-ins are 
'players' they tend to only need installing once, whilst providing the 
developers with a great deal of customisable functionality. 

Once an administrator has decided to adopt a particular plug-in then it is a 
simple task to either place it inside the firewall, or install it on each 
machine. This is what most people do for Acrobat, Flash, SVG and so on, and 
I think XForms will fall into the same category. It will be a one-off 
decision by the administrator, not an arbitrary day-to-day decision by users 
'freely downloading'. 

(I could go on for hours about the 'myth of the thin client' - just take a 
look at the amount of software we have on our machines to 'play' audio, 
video, images, SVG, spreadsheets, RTF documents, PDF, etc., etc. That's the 
'thin client' you need these days, just to work on the internet.) 

> So, to create content that is truly accessible by the masses, a 
> server-side solution is the answer. 

Our first XForms processor was a server-side one, but we decided it wasn't 
worth the effort, since you don't get a great deal of extra functionality. 
Yes it's true, you do get a standard way of expressing your forms before 
conversion, but hasn't everyone got one of those anyway? 
At some point you have to convince people that the additional functionality 
they achieve is worth the download. And I have to say that when people see 
some of our sites, with XForms, MathML and SVG on the same page, all 
interacting with each other, it's difficult for them to go back to their 
boring old web pages! 

One final point about the adoption and uptake of XForms; I agree with you 
that we want to make XForms 'accessible to the masses' of users, but I also 
want to see it made 'accessible to the masses' of developers, in much the 
same way that HTML was usable with notepad and the refresh button. 

For that to happen you need a solution that doesn't rely on the individual 
developer having a server - which incidentally is the major motivation 
behind the free plug-in we have developed. 



Mark Birbeck 
Co-author Professional XML and 
Professional XML Meta Data, 
both by Wrox Press 

Download our XForms processor for IE 
at http://www.FormsPlayer.com/ 

Managing Director 
x-port.net Ltd. 
4 Pear Tree Court 

E: Mark.Birbeck@x-port.net 
W: www.x-port.net 
T: +44 (20) 7689 9232 
Received on Thursday, 20 February 2003 16:14:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:07 UTC