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

RE: Question

From: Dan G. Switzer, II <dswitzer@oar.net>
Date: Thu, 20 Feb 2003 20:20:33 -0500
To: <www-forms@w3.org>
Message-ID: <000f01c2d947$6f5a27c0$9801a8c0@dansnbk>

I was under the impression that the solution they were working on was
client-side based--meaning that the parsing/rendering was all done via a SWF
file. I might be wrong about impression though, if I'm not though, it's
probably not going to be the best solution for clients running older
machines.

Here's what their website says:

"Introducing DENG, a W3C compliant XHTML / CSS / XForms rendering engine
written entirely in Flash MX Actionscript."

If a unique SWF was created for each Xforms, then the flash file would be
extremely lightweight, cacheable (by both the client and server,) and
extremely efficient (you'd also be able to do things and keep them Flash
compatible.)

-Dan


> -----Original Message-----
> From: John Boyer [mailto:JBoyer@PureEdge.com]
> Sent: Thursday, February 20, 2003 5:14 PM
> To: Dan G. Switzer, II; www-forms@w3.org
> Subject: RE: Question
> 
> I believe the Mozquito guys, who are now a subsid of SAP, are doing
> this...
> 
> John Boyer, Ph.D.
> Senior Product Architect
> PureEdge Solutions Inc.
> 
> 
> -----Original Message-----
> From: Dan G. Switzer, II [mailto:dswitzer@oar.net]
> Sent: Thursday, February 20, 2003 1: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 20:31:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:54 GMT