Re: Web Futures (was: HTML Futures (was: to <P>...))

On Sun, 18 Aug 1996, Paul Prescod wrote:

> I think that "HTML subtypes" is a dead-end alley. Better to move directly to
> architectural forms or "SGML subtypes". Documents on the Web will often fit
> into many different categories. There must be a way of declaring their
> adherence to different architectures. Either SGML archforms or DSSSL
> extensions could allow this.

Well, almost. You want to hear my vision of a perfect future? (I know you
don't but I'll put it out anyway)

MIME types already provide a good way of describing the type of a document,
and are already used universally with HTTP. URLs are not restrictive in any
way in defining resources on the Web (whatever the Web *is*, of course, but
that's a longer story), regardless of type.

Now, if you could make sure that *everyone* could read at least a couple of
MIME types from each category (say, HTML, PDF, PS, WAV, AU, GIF, PNG, JPG,
MOV, AVI and several more) which isn't that far from most sytems'
capabilities already (I can view all of these formats on both my Mac,
Windows, and Linux systems, except PDF I think, on my Linux box) and instead
of having a user agent (I always hated the word browser) that just does the
HTTP thing and gets the document and then pumps it into a viewer. HTML
(especially 2.0) is *IDEAL* for being the superstructure for this.

Now, all you have to do is update a couple of file types (like images and
layout documents) to be able to have hyperlinks inside them. Integrate this
system into your operating environment so *any* viewer can make *any* call
to a URL and that user agent I mentioned will fetch it and open the correct
program for it.

How do you make sure you have all the apps? How about a service webbed
through the Internet in the same way that DNS or IRC servers are (i.e.
although there is only one definitive list of hostname-address mappings and
only one actually list of IRC channels, you only have to talk to your local
server to work) that have the task of cataloguing apps for *all* platforms
according to MIME types. User agent trying to download an unknown document
type? Fine. It queries the nearest server and gets a list of available
applications. You can even tune it so it checks periodically for updates, or
even ask the server to automatically give it the apps that are "most often
requested" so you will have adequate viewers for the most popular document
types. The server would only give a pointer to the app, not store the files
itself. So one could get it through FTP from a central site.

Sounds infeasible? Give the Internet a decade and come talk to me about the
bandwidth we'll have, and even other things will be feasible, like renting
storage space over the Network instead of buying a new hard disk every time
your older one is full.

I think that the main problem in conception is that the Web is *not* based
on HTML. It is based on HTTP, the URI specification and the idea of a
world-wide network of hypertext documents. Hypertext is really just the idea
that a part of a document leads to another document, and it's been used for
years (if you don't believe me, open any Windows help file). If we expand
the idea that a part of a document leads to another document into other
document types, we've gone the first step: One no longer needs to bother
that HTML can't display properly, he uses another format instead. Examples
are already here, and VRML is one, while Java is another.

Wow. That was long. Any thoughts? (more to the point, did anybody even
bother to read it up to here? :-))

= Stephanos Piperoglou = = =
  Four lines in a .sig can't say enough about why you should visit my page!
"I want peace on earth and good will toward man"
"We're the United States Government, we don't do that sort of thing!"
                                    [ from the film "Sneakers" ]

                                                       ...oof porothika! (tm)

Received on Sunday, 18 August 1996 14:33:22 UTC