RE: Question

Hmm, not sure why we don't think this can be done with JavaScript.  We have a server-side transformer that converts XForms into HTML and JavaScript.  The majority of the XForms specification can be implemented, including relevance, repeat and insert.  There are only a very few events that present issues because of intrinsic HTML form capability or because it doesn't make sense.  For example, valueChanging, invalidDatatypeError, activate and valid events cannot directly be implemented because HTML form elements do not have equivalent events so simulated procedural methods are used.  Others are not applicable if an XForms document is not being processed such as modelConstruct, modelInitialization, initializeDone, UIInitialize, formControlInitialize and traversalError events.

I think the huge savings is one of the ideas behind XForms - move client-side logic from markup to the browser.  Things become attribute-based instead of needing to create code, over and over again implementing the same stuff.  This same benefit can be realized by auto-generating the code based on XForms attributes on the server side.  To me, it's a significant development cost savings, and it produces repeatable results.

I understand and agree with not wanting to run a server for just creating content.  This can be solved by creating the content in notepad, running an application on it, then loading the result into a browser.  Or, use a plug-in for development and a server-side solution for deployment.

Gary Sikora,
Progeny Systems Corp

-----Original Message-----
From: Dan G. Switzer, II [mailto:dswitzer@oar.net] 
Sent: Thursday, February 20, 2003 4:53 PM
To: www-forms@w3.org
Subject: RE: Question



Does anyone know of a company working on a server-side model to convert XForms docs to Flash? It would seem one of the quickest methods to get the populous to adopt XForms would be to leverage the technologies that are already out there.

While I've written a JS-based API that works w/NS3+ that handles a lot of the backbone of what an HTML/JS translation of an XForm document looks like, there are still some issues that you have w/traditional HTML elements that interfere w/the implementation of XForms.

It would seem to me, a server-side solution that converted XForms to a standalone SWF file would be a really solid way to get the community to adopt the standard in their development.

I think I remember someone mentioning they were writing an XForms parser in Flash--but I think a generating the SWF on the fly would be more efficient for users w/slow PCs. You'd also be able to cache the SWF files, so it's not like you'd have to regenerate them everytime.

Any opinions/comments?

-Dan

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Doug Mcneil
Sent: Thursday, February 20, 2003 9:57 AM
To: www-forms@w3.org
Subject: RE: Question

Hello, 
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. Regard's 
Doug McNeil 
Architect 
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 

Gary, 
> 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. 
Regards, 
Mark 

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 
London 
EC1R 0DS 
E: Mark.Birbeck@x-port.net 
W: www.x-port.net 
T: +44 (20) 7689 9232

Received on Thursday, 20 February 2003 17:54:58 UTC