Re: HTML should *NOT* HTTP

• Mail folder: WWW Talk Apr 94-present
• Next message: HALLAM-BAKER Phillip: "Re: Security/compliance"
• Previous message: Robert S. Thau: "<meta information>"
• Maybe in reply to: Nick Williams: "HTML should *NOT* HTTP"

Errors-To: listmaster@www0.cern.ch
Date: Wed, 1 Jun 1994 20:18:32 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406011816.AA22008@dxal18.cern.ch>
Errors-To: listmaster@www0.cern.ch
Reply-To: hallam@dxal18.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: hallam@dxal18.cern.ch (HALLAM-BAKER Phillip)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: HTML should *NOT* HTTP
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

In article <712E@cernvm.cern.ch> you write:

|>>From the recent WWW conference it became evident that many people had a
|>confusion between HTML+ and HTTP.  Specifically, there was a large body
|>of opinion towards placing type information into HTML.  For example,
|>placing within the HTML+ document information such as "here's a picture,
|>and the alternative text for the image is blah blah blah".  e.g.
|>	<FIG src=/some-image>
|>	If you don't have image viewing capability, you'll see this text
|>	</FIG>

The purpose of this is to encourage people to write the text. At the end of
the day most people do not have editing tools capable of editing multiple
format documents.

Why are we so interested in the text? Simple the images do not work in
braille or in a voice synth.

|>The belief is that clients which cannot display images (or audio, or
|>whatever) should be able to display something.  IMHO, this model this
|>seems to be completely incorrect, as it merely duplicates (badly) the
|>format negotiation protocol already present in HTTP.

To do it properly would require browsers to be able to include text chunks.
Unfortunately this is not really feasible within SGML.


|>It was even suggested that many different types of alternatives to be
|>inlined within a document (e.g. <alt type=audio/basic>DATA</alt><alt
|>type=text/plain>Hello world</alt>), which could lead to huge data files
|>being downloaded, when the user only EVER wants to see one of the types
|>of data object.  The best comparison here is between audio and images.
|>A visually impaired client will typically only want the audio
|>descriptions of images and if it has to download the complete image
|>every time it asks for a soundbite, it will double (at least) the amount
|>of data the client needs to download.

No there is a coherent model. HTML contains only text and pointers to audio,
images etc. We have drawn the line at incorporating SMILES strings or
TeX or whatever. These can be linked via MIME though.


|>When you request a URL from a server, you transmit information
|>specifying exactly what data formats you understand.  If you have a line
|>mode browser, it will not request objects of type image/gif or whatever.
|> This allows the server to find the best "fit" to the requirements and
|>return that object and only that object. This also means that the type
|>of object returned may very well NOT be the same type as determined by
|>heuristics on the URL extension.

But there is no tage to state that you only want some HTML that does not
inline images. It is perfectly permissable to request a HTML that inlines
image formats that you cannot display and for the server to serve it. In
fact this is required, the server cannon know a priori what type of data
a link points to.

--
Phillip M. Hallam-Baker

Not Speaking for anyone else.