Brian
On Wed, 25 Jan 1995, C. Bailey wrote:
> 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.
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/