DTD meta data for XML viewers

[Trevor Turton]

(this is a retransmit - the previous version was truncated)

In an earlier note I spoke about the need to associate compose-time
meta data with DTDs to allow XML editors to assist with the process of
document composition.  Another major class of meta data that needs to
be associated with DTDs is information on how the associated XML may be
rendered - most usefully, by identifying programs which can perform the
required rendering.  The classic browser renders HTML on computer
screens, and also on the printed page.  The same will be required of
XML browsers, and some will also render XML documents to voice for the
visually impaired, to braille for the more profoundly impaired, and to
other media as new needs and technologies arise.  Hence we may need to
associate a list of rendering programs with any given DTD, covering the
various media types supported.

Current browsers attempt to render "all" HTML tags, but HTML is a
moving target.  Browsers are already very large, and need to be
supplemented by plug-ins to handle various MIME types.  Once XML is
generally available, we must expect a proliferation of DTDs by various
parties for varied purposes.  While a single generic XML editor may do
a good job of checking the syntax of documents developed against these
DTDs, it cannot render them.  Realistically, creators of novel DTDs
will have to create code that renders them.  And once a useful body of
DTDs has been developed, authors of XML documents will want to use DTDs
from many different independent sources in a single document.

No browser manufacturer will be able to bundle rendering code for all
DTDs into a single product.  We need to define a standard way in which
browsers can obtain and use code to render DTDs that were not even
invented when the browser was created.  This code distribution
mechanism may be something between a plug-in, which requires manual
intervention to install and persists after use, and a Java applet,
which installs automatically and is discarded after use.  For the
purpose of this note I will call them "renderlets".  We need to arrive
at a standard way of associating renderlets with DTDs as meta data, so
that browsers that encounter a DTD for the first time can find and
obtain the code required to render the XML defined by the DTD.

Some vendors may wish to create platform-specific and even
browser-specific renderlets, giving rise to the need to associate a
list of different renderlets with a given DTD.  Most authors of DTDs
will want to implement only a single renderlet to save effort.  This
would have to be platform and browser independent, and Java is the
obvious choice.  We need a standard way for Java renderlets to
interface with the browser that invokes them.  And since XML entities
may be imbedded in other independently created XML entities, renderlets
must also implement the same standard interface when they invoke
imbedded renderlets.  This interface will have to be richer than the
current spartan <APPLET> tag, which makes an unconditional demand for
display space.  Any given XML document may in the future be rendered on
anything from a IMAX screen to a Dick Tracey style watchtop display.
Renderlets will have to share the space available.  The browser will
have to sum the space demanded by the renderlets it hosts and compute
an overall compression factor.  It will have to communicate the
compression factor back to the various renderlets so they can make an
informed decision about the level of detail that they display - if any.
The renderlet interface will need to include a specialised Java
LayoutManager to facilitate layout and space negotiation.

Given this approach, the browser itself can become a fairly small and
simple shell, with all XML elements implemented by downloadable
renderlets.  A cottage industry in renderlets may emerge, paralleling
the VBX and OCX industry that Visual Basic spawned.  Competing versions
of renderlets for commonly used DTDs will arise, and browser owners
will be able to shop around for the renderlets that best meet their
needs.

If there are concerns that fetching renderlets will generate excessive
network activity and make XML browsers too slow to use, browsers (and
http proxy servers) could be enhanced to allow priming of their cache
directories.  Pointers to local copies of often-used renderlets (and
DTDs for that matter) could be loaded into the browser's (proxy
server's) cache directory upon initialisation.

Trevor Turton

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)