As an alternative (IMHO) I would suggest instead of extending HTML to cope
with every specialised format one might wish for (tables/spreadsheets,
mathematical formulae, inline sounds and video clips...) one could, at the
cost of the luxuries of having these things presented 'in-line' simply
feed them into software which can handle them, without having to translate
them into HTML.
The idea is analogous to that of the [application] message type in MIME
(rfc1521) which specifies that a message is to be processed by a specified
application. This could either be implemented by extending the anchor tag:
<a href="filename.type" use="application.name">
or more flexibly by simply having the browser assign a set of applications
to a set of filename extensions, similar to the MS Windows File Manager.
Then when a link to a non-html file is selected, the chosen application
auto-loads using the specified file and either displays it or executes it.
This is what happens in certain browsers when a '.gif' file is specified
in this way, and the extension to other file types would presumably not be
too complex?
Although there are clearly difficulties with this approach (e.g. the need
for software to read each file type, security issues with executable
files) I would say that by choosing a few basic file formats (eg
postscript for page description, LaTeX for formulae) to provide readers
for (perhaps bundled with a browser) coupled with existing applications
(eg MS- or X-Window software) one could open up vast new panoramas of
existing data in every form, leaving HTML as the backbone to support a WWW
fleshed out with all the data currently inaccessible in unreadable
formats.
Charlie Bailey
--
/~~~\
( @ @ )
----------------------------oOO-(_)-OOo----------------------------------
Charlie Bailey Bristol University [email protected]
-------------------------------------------------------------------------