8.1 Further developments

What's next? This section contains rather miscellaneous ideas for further work. They're ordered from most to least work, but on the basis of about two seconds' reflection, so nothing should be pinned on this. The work involved seems to correspond rather neatly with their expected utility.

XML

I'd like to support XML (see Section 8.2). This requires a little development of the DTD but, more substantially, also requires investigating what level of support we can reasonably expect from users' browsers. There is a great deal of work being done on XML at present (mid-1999) - when the developments settle down we can start to exploit them. There's a big range of possibilities here, so this could be a smallish task or a huge one, depending on what we wanted to do.

Searching

I'd like to support sophisticated searching. The Starlink HTX system allows some context-based searching (see SUN/188: 8 SEARCHING FOR INFORMATION IN DOCUMENTS), and it should be easy to support this and more in the SGML set. This would involve finding a suitable SGML-aware search engine. The BNC's SARA server might be a possibility: I think it's free, but I haven't yet investigated the extent to which it's specific to the BNC, or to its windows client.

Table support

I'd like to support more of the Oasis table subset (see Section 4.8). I can add support incrementally, as folk suggest priorities.

CSS stylesheets

At present, the formatting is controlled by the parameters file. I could remove this and instead distribute a CSS stylesheet, which would also allow individual users to selectively override things they didn't like.

Include elements for Examples, Notes, Warnings?

How important is this? It might be nice to have explicit support for these, but I don't want to bloat the DTD with too many features, so it's a question of balance. I'd thought of something like: <callout type=warning>Switch the computer on before attempting to read your mail</callout>. Having `type' be `example', `note' or `warning' gives the thing attractive symmetry, but would this improperly bundle different things together.

Link colouring

Output, for example, a little coloured dot (4x2 pixels) before all or some links, indicating what type of link this is. For example, unadorned links are to other parts of the same document (ie, <ref>), a red dot indicates a reference to another Starlink document (ie, <docxref>), a blue one to a miscellaneous URL. I've implemented a similar thing on another system, and it's both unobtrusive and rather helpful.