There are several considerations that are shared by both Web applications and compound documents as regards SVG user agents. While this document deals primarily with Web applications, points touching upon both will be indicated.
Several problems present themselves when developing cross-platform browser-based Web applications. Without the ability to perform reliably on a variety of systems, in the use's choice of browser, most of the utility of having a Web-based application is lost. Typically, these problems arise from feature and funtionality differences in the Adobe viewer. The Batik viewer, while an excellent product for server-side or developmental use, is not not ideal for deployment of Web-based apps, requiring a somewhat complicated installation procedure and displaying only SVG (rather than additional formats such as HTML); it is unclear what advantage deploying a Batik-based application would be over deploying any Java-based program that requires installation on the user's system.
Some of the problems inherent in the ASV and other UAs are addressed in SVG 1.2, if implemented correctly. Among these are the lack of proper keyboard support on all platforms, and local file access. Others that are not mandated in the Specification, but are particular to the UA include, for other browsers than Microsoft Internet Explorer: the difficulty in installation; the lack of interdocument communication; and the lack of inline SVG support,which has garnered more interest lately, largely due to the ease with which XSLT-transformed HTML+SVG documents can be displayed in IE. Inline SVG is also hampered, even in IE, by the limited interactivity, the lack of CSS support, and the inability to print the SVG content. Given that many developers wish to leverage other W3C technologies such as XSLT and XSL-FO to create compound documents and even Web apps, this presents a challenge that should be taken up by UAs (in this case SVG viewers, since we cannot depend upon Microsoft to support true mixed namespaces, given recent announcements that IE 6 is the last iteration of that Web browser). Given these inconsistencies, many authors and developers will be frustrated by the same issues that plagued Web development thoughout the browsers wars of the 1990s. It is to be hoped that a new generation of UAs will address these concerns.
SVG applications can be expected, in general, to create other Web documents (including compound documents); examples include PDF-style static documents intended for print, animations, and even non-SVG output. An instance of the latter might be a graphical drag-and-drop representation of an organization chart that generates an XML representation in some other (non-graphical) format.
But many (perhaps most) SVG-based applications not only use SVG as a front end, but are intended to create graphical content, be it artistic (such as illustrations) or data-driven (charts and graphs, CAD and GIS representations, etc.). This content, while ideally suited for the Web, is of limited utility if it cannot be used in desktop applications as well. Often this content needs to retain its interactive aspects, and so needs to stay in SVG format, but this is not always the case. It is unrealistic to expect desktop applications to deal properly with SVG content while SVG still lacks much support; for this reason, we believe that UAs should be encouraged to support saving or copying rendered SVG as a raster.
Most content created by SVG applications needs a method to share it with the intended audience. This need can be met by the ability for UAs to open and save documents to the local file system, or by transmitting them to other systems or the server using new access protocols allowed in 1.2. While this does raise security concerns, these concerns might be addressed by incrementatl development of a UA; intermittant developer releases of a viewer might be developed after a public release, so that possible security exploits can be explored and fixed. It is important for adoption that SVG not get a reputation as a security risk.
In addtion to saving content, the methods mentioned above might also be used to save the state of an application for later restoration by the original user or other users. Protocol support will also allow for simultaneous distributed content creation or maintanence. Proper implementation of these features by UAs is imperative to the success of SVG applications.
There is an argument to be made for a standard set of UI controls, but we are against the inclusion of most high-level widgets in the specification, for a number of reasons. First, SVG already provides most of the requirements to build custom controls; this will be made easier still with SVG merger with XBL. Second, if a widget set is to be defined, it should be a separate specification, like that of Mozilla's XUL, which can include semantic information that is not necessarily appropriate for the presentation layer that is SVG. A possible exception to this ban on widgets is the possible inclusion of a "medium-level" layout manager, such as a table or grid. Experience by the authors has shown that developing this in script only can be too much of a burden on the use system, with serious performance issues.
One way to address this concern is to define a manner in which plug-ins can interact with and be enhanced by other plug-ins. Examples include XSLT processors, text-to-speech synthesizers, and speech-recognition modules, or specialized modules to perform specific programmatic functions in C++, Java, other languages (such as Scheme), to supplement or replace script.
A major concern is how easy it is for a novice author to create SVG documents and applications. To a degree, commonly-available XBL components can be used as declarative elements (from the point of view of the author using these components), but this should not supplant native declarative development, such as might be used for navigation or drag-and-drop.
Of special consideration are accessibility issues. To a large degree, these are best dealt with in other places, such as speech synthesizers and XML dialects that contain sophisticated semantics such as RDF or XUL. However, it is particularly important that the SVG Specification define a manner in which other standards, specifications, and non-SVG UAs can interact with SVG in order to make it easy to achieve this easily and seamlessly, in the same manner as consideration is being paid to XForms. While most semantics are best dealt with in other specifications, there are certain aspects of SVG that could be used to help screen readers and other Assistive Technologies; specifically, <title> and <desc> elements, groupings, colors, relative spatial data (based on x-y coordinates), and intersection information. Intersections could be far more useful for GIS, CAD, mathematical representations, and screen reader interpretations if the viewer would provide points of intersection, rather than just boolean values.
SVG has great potential to serve as an application framework, but much depends on how well it is designed to work with other technologies, and how well it is implemented in UAs.