- From: Angelo Borsotti <angelo.borsotti@alcatel.it>
- Date: Wed, 22 Sep 2004 09:29:33 +0200
- To: www-svg@w3.org
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