To Do List for Mozilla SVG Implementation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Authors:	Jeremy Lea

Last Updated:	1999/10/28


This document is a discussion on a number of issues around the SVG
implementation.  It is not in order of importance, but in the order in which
issues araise as you perform a top down investigation of the code.

1.  Regstration of the MIME type.

Although SVG does not yet offically claim the MIME type "text/svg", the
implemetnation needs this to recognise the document code.  Currently the
MIME types are hard coded into the mime section of the network library. 
This is bad, since it means that components cannot register new MIME types. 
The layout engine should be doing this registration.

Design:  Each component has a initailisation function, which is called once
as it is loaded.  This function should call some initailisation method on each
of the document types contained in that library, and these should be able to
register their mine types, along with the factory for the document objects.

Status:  Needs discussion.


2.  Testing for document types.

Currently the code searches through the various MIME types known by the
layout library, looking for the corect type, before calling the document
object factory.  This needs to be generalised to something which can cope
with new types being added on the fly.

Desgin:  When the document objects are initalised (see #1), a linked list of
types should be built, and this list should be searched.  This, however,
requires that all document object factories have the same parameters.

Status:  Needs discussion.


3.  Documents and documents fragments.

The SVG implementation currently consists of a nsDocument derived object,
which performs all of the selection of element types.  This needs to be
changed to a default namespace, so that the document object can allocate
content based on namespace.

Design:  Not really one yet.

Status:  Needs design.
