[6219] in www-talk@info.cern.ch
Re: Format Negociation in Practice [Was: Versioning HTML at the server]
daemon@ATHENA.MIT.EDU (Chris Lilley, Computer Graphics Un)
Tue Oct 18 18:51:49 1994
Date: Tue, 18 Oct 1994 23:48:07 +0100
Errors-To: postmaster@www0.cern.ch
Errors-To: postmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
In message <9410181625.AA21119@austin2.hal.com> Daniel W. Connolly
wrote:
> But I don't think the technical details are the problem any more:
> we have to make it easy for information providers to _use_ format
> negociation.
> I don't know if this means more tutorial documentation, or some
> http server configuration options, or changes to clients, or what.
First we need some way for clients to say what they support - accept
text/html is too broad a brush - and have this published so everyone
does it the same way.
Either that, or we insist that clients deploy the full feature set,
ie all existing clients must support all of HTML 2, future clients
that support HTML 3 must support all of it. I think this second
solution is unworkable.
Next, there must be some method in the two most popular servers
(CERN and NCSA) that does something useful with this information, as
standard, right out of the box.
Ideally this could be configured so if you have loads of disk space
but cycles are tight, the server stores multiple versions of a
document; if you are short on disk but have a zippy CPU it down
converts from HTML 3 to 2 each time.
Exactly what the server should do is up in the air right now. But at
the end of the day what we want to achieve (IMHO) is clearly this:
1) it is easy for someone to put a document that uses HTML 3
features onto a server
2) it is easy for someone with an HTML 2 browser to read a version
of that document.
Clearly, the down-conversion must be done by software on the server
side because the document author needs to maintain only one master
document, not a whole bunch of versions, and if the clients knew
enough to convert 3 to 2 they would be the best part of the way
towards being 3 clients anyway.
As a result, there will be a big increase in HTML 3 documents on the
Web - because putting them there will not break existing clients.
Therefore, clients will support more 3.0 features because the
servers will be able to serve it to them. We need clients with 3.0
features so that the spec can be tested out in practice, argued
about, etc. Speaking of which is Dave Raggett's HP browser available
for alpha yet? I have a nice 735 workstation it could go on ...
The biggest problem, as I see it, is figuring out what a server side
program should do to a 3 document to down-convert or simulate each
of the 3 features.
The simplest solution is clearly to remove the information.
It might be possible to strip out the table information, render it
on the server side, create a bitmap and then create a munged
2-compatible document with the inline bitmap. This requires some
cycles, sure, but if it is only done once when a document is added,
by a program that comes with the server as standard, it should not
be too much trouble for authors to do. Perhaps the server could
invoke the conversion the first time the document is requested and
squirrel away the munged file transparently.
> What can we do to avoid:
> "Click _here_ if your browser doesn't support tables."
> "Click _here_ if your browser doesn't support multilingual
> docs."
> "Click _here_ if your browser doesn't support figures."
> "Click _here_ if your browser doesn't support math."
> "Click _here_ if your browser doesn't support stylesheets."
I agree we must do our utmost to avoid this situation.
And yes, once all this is in place we need tutorial diocumentation
on how to use the 3.0 features and how to serve 3.0 documents. I
will help write this documentation once there is something to
document (I am a technical author in my day job ;-) )
--
Chris.
