21 Extensibility

(This section is still under construction.)

It is highly desirable that SVG provides a general, robust extensibility mechanism which allows the feature set of SVG to be enhanced without having to wait for SVG specification to be updated and new SVG implementations to be deployed. The general model is that extensions could be implemented in scripting (e.g., ECMAScript), Java or CLSID/ActiveX, with each option offering different degrees of platform-independence, performance, and universal availability.

Here is a mini requirements definition for an extensibility mechanism:

1. Provisions for alternative renderings in standard SVG (i.e., SVG without extensions) in the event that a given extension is not available.
2. Allows for the possibility of extensions that are built into a given SVG processor. (For example, a particular SVG implementation might choose to have custom built-in SVG functionality in order to serve the special needs of a particular set of users.)
3. Allows for the possibility of extensions that are added on dynamically at run-time via scripting (e.g., ECMAScript), Java/JAR or CLSID/ActiveX.
4. Leverages and conforms to others Web standards directions.
5. Provides the extensibility mechanisms for the following:
   • custom paint servers (i.e., fill and stroke types)
   • custom object servers (e.g., 3D lettering) that allow for whole new object types to be added to SVG beyond the basic types of paths, images and text.
   • Filter effects that allow transforming vector and/or raster data into other vector/raster data before painting.
   • Compositing effects that provide hooks for custom blending the object into its background.

The exact mechanism for providing this capability hasn't been decided yet.