For the descendants of <sheet> elements, some elements are DocBook elements and some are our own invention. Currently, we use an "ipython-" prefix for those tag names that we have created. If we were being good XML citizens, we would instead define a namespace and make sure all of the elements have the appropriate namespace prefixes. Currently, we can't use a namespace for the DocBook elements because some of the tools we use are not yet DocBook?-namespace-aware. While it's possible to work around that issue, the XML library that we use has inherited a somewhat clunky approach for handling namespaces in code. If we could throw around tag names like "ip:block" or "db:para" in our Python code, then we would use namespaces and be very happy about it. Unfortunately, we have to deal with "{http://projects.scipy.org/ipython/notebook-xml}block", etc. We will revisit this issue as lxml grows better namespace handling.

We expect to fully handle other namespaces like those for RDF, MathML and SVG since we probably won't be directly manipulating their contents using lxml.

RTK 2005-09-27: I've grown a better way to handle namespaced tags in code. In notabene.xmlutils I've defined a class that encapsulates an XML namespace and its tags. I think we will move forward with converting to namespaces. Every non-DocBook? tag will have an ipython namespace "http://projects.scipy.org/ipython/notebook-xml" with an abbreviation "ip". Those tags whose names currently contain "ipython-" will have that prefix stripped (e.g. <ipython-block> -> <ip:block>). DocBook? tags will have the namespace "http://docbook.org/ns/docbook" and an abbreviation "db" (e.g. <para> -> <db:para>). Extensions to the format will need to be in their own namespace.

Another motivation for moving towards namespaces is that we are now considering extensions to the system. At SciPy '05, Daniel Wheeler made an excellent suggestion for how notebooks might be used. One can imagine building a doctest-like system using notebooks. Certain cells would be marked as tests so they can be reexecuted and their outputs compared. The notebook would serve as a single source for these tests. The code itself could be extracted without its output to form separate example scripts. Being interactive, a user could immediately explore a failing test. Using a notebook to hold these tests solves a big problem with regular doctest: cut-and-paste from an interpreter session into a docstring can cause problems with characters that ought to be escaped. This is such a great idea that it will almost certainly be part of the standard notebook package. However, it will also make a great example of how to extend the system (and indeed, an actual target so that we can properly develop the necessary hooks), so we are going to put all of the necessary tags into their own namespace.