Comments to SVG 1.2 spec

Hello,

I would like to submit to you some comments on the SVG 1.2 spec.
They are of a general nature. I hope they can be useful to help
in choosing the direction to which the spec is evolving.
W3 specs, as any other international standard, take quite some time
to get implemented. This could be seen as a disadvantage, but we can
see it also as an opportunity: the one to make some significant step
forward.

We are seeing a number of standards that are being developed and that
address areas that are often overlapping, at least partly.
Let's consider first the authoring of web pages. Web pages have some
distinct characteristics with respect to the authoring of documents;
however, they share quite a lot with them. Documents, be them technical,
ads, or whatever, do mix text and graphics. What we need is basically
a seamless way of doing it. HTML, XHTML, XML have developed first and
somehow independently from SVG. My suggestion is to integrate them as
much as possible. A SVG image could be a foreign object in an HTML
page, but should not in an XML one. The author should be allowed to
mix seamlessly text and graphics in the very same file.
I have seen the text element be improved in SVG 1.2. I would suggest to
go even further. As a good reference example we could take TeX (although
it is quite poor about graphics): in it all objects are just things to
place somewhere, be them glyphs or pictures. All of them have a width
and
a height; placement takes them into account and can be done in a
relative
way. I.e. an object can just be placed adjacent, or above (below, etc.)
with respect to the previous one. The concept of XML of separating the
data from their presentation falls short of the mark if authors are
obliged
to specify absolute coordinates for positioning objects. My suggestion
is
to support relative positioning in all objects.

The second area in which SVG is playing an emerging role is the one of
interactivity. After all, we could use SVG as any other vector graphic
language to represent the contents of the windows of many interactive
applications. It would be just another formalism, and there would be
nothing really new (apart from being standard, which is quite good).
Think for example to represent Motif widgets with SVG.
The real plus of SVG is that it is in the realm of internet, and
therefore
it could bring interactivity over internet.
HTML forms (and then XFORMS forms) bring some level of interactivity to
web pages, but limited to text basically. This means that they allow to
implement internet applications in which the interaction is basically
one-way
and text only. The user fills forms and sends them to some server,
waiting
for an answer (this brings my memory back to 3270 IBM terminals).
DOM and scripting and animations add some kind of interactivity, but
that
is limited to some small things that can be done locally in the browser
without some real exchange of information with the server that is bedind
the stage.
SVG is supporting scripting, and events, and integrating with XFORMS,
etc.
It has all the capabilities to represent any interactive window with
input fields and objects that can be clicked on, and also with dynamic
content that can be displayed. Thus, why limit SVG to display forms?
If we had a standard way to report events to web servers, and also to
make web servers push data to web pages, we would have finally provided
the way to exchange data in a bidirectional way from SVG pages and web
servers. Forms would then become just an example of interactive pages.
My suggestion is thus not to restrict SVG to support XFORMS, but to
provide
instead a means to communicate events and receive notifications from the
net.

Angelo Borsotti
Senior Director, Software Technologies, Alcatel OND

Received on Wednesday, 22 September 2004 09:04:26 UTC