W3C home > Mailing lists > Public > www-forms@w3.org > August 2004

RE: [svg-developers] Re: SOAP Calls from SVG

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 2 Aug 2004 00:10:32 +0100
To: <svg-developers@yahoogroups.com>
Cc: "'Jan-Klaas Kollhof'" <keyjaque@yahoo.com>, <www-forms@w3.org>, <w3c-forms@w3.org>, <formsPlayer@yahoogroups.com>, <HektorK@frogware.com>
Message-ID: <00b101c4781c$bf18d6b0$0a01a8c0@W100>

Hi Jan-Klaas,

> nice subject :)


> SVG1.2 will bring sockets and better http support.
> This will allow us to even make SOAP calls (using 100% SVG 
> without using things like ActiveX or special viewer extensions).

I have to say that I'm finding myself more and more against this approach.
It seems that the goal is to cram as much into the SVG language as possible
to try to make it come close to a 'real' programming environment. But what
do sockets and protocols have to do with vectors and Gaussian filters? In
fact, applications that I've seen that are written 'in SVG' are little
better than applications written 'in HTML'; they both consist of some
mark-up for the UI, coupled with enormous amounts of script for everything

In my view the key to solving some of these problems is better integration
between standards. Of course that's no easy feat when there are so many
vested interests, but this topic does illustrate the point well - why not
leave all the data management, schema validation and so on to XForms, and
then use SVG for the UI? XForms 1.0 already has strong XML submit and
receive support, as well as schema validation, and XForms 1.1 will have full
SOAP support.

An example of using a weather web service to retrieve some data from a zip
code (using XForms) and then show the high and low temperature ranges for
the next five days (using SVG) is available here:


The demo requires the Adobe plug-in and formsPlayer, an XForms processor for
IE. If you don't have formsPlayer and want to try this demo out, you can
download it from:


Note that the technique used in the example simply involves registering for
XForms events that allow us to be notified when data has changed, and then
using script to poke values into the SVG at the right places. In this
example we set the height and position of the bars to show the temperature
range, but it could obviously be anything you like; the important difference
from current techniques is that you can now make use of all the
model-related features of formsPlayer and XForms:

* full schema validation with events to tell you when data goes valid or
* ability to submit and receive documents in a variety of serialisations,
including XML and multipart-MIME
* create spreadsheet-style dependencies between data, and let the engine
keep it up-to-date for you

and much more.

A more refined approach than the one shown here is where XForms widgets are
themselves implemented using SVG. We will be making a formsPlayer technology
preview available any time now, which does exactly that, and in fact one
demo that will be available is a 'drop-box' that is an SVG map, allowing the
user to choose an airport.

But in the meantime, given the current discussion on web services and SVG I
thought it worth drawing SVG developers' attention to the XForms/SVG/script
technique illustrated by the weather sample. In the technology preview it
will be possible to remove the script that wires the XForms and SVG
processors together, so anyone wishing to work with this current approach
will be able to take their applications forward.

If you are not familiar with XForms, and want further examples of using
XForms to access services, there is a non-SVG version of exactly the same
weather service here:


and a sample that accesses Amazon, here:


We also have a very old Google demo here:


So in summary, those using the Adobe plug-in with IE can now use XForms to
give them the data management side, and then use SVG for the UI.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Sunday, 1 August 2004 19:11:00 UTC

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