> > There must be some misunderstanding here. My argument was 1) introducing
> > format negotiation for table does not justify the cost and/or solve the
> > problem. 2) an old net convention is useful in transition period and we
> > should see it being applied appropriately. I am not advocating a paradigm
> > shift.
> Luke, why are you fighting so hard against content negotiation??
You only believe you can't do it, Luke. Use the force, Luke.
Sorry, but you should see the Yoda graphic on his home page! *grin*
More seriously, Luke has raised some reasonable points about a transition
strategy between the capabilities, right now, of existing servers and
browsers and the capabilities of HTML 3.0 browsers or those that are heading
in an HTML 3.0 direction. He has suggested a strategy based on existing
behaviour of clients and those famous words about strict send/lax receive.
> It's not a
> "paradigm shift" at all. You're clearly willing to put effort into your
> pages to make them viewable by everyone - why cramming all that into one
> index.html file is better than creating two logically correct pages and
> naming them index.html and index.html3 is beyond me (though I see you're
> running NCSA 1.3 which doesn't yet have native content-negotiation (very
> soon, though!),
You can sort of see Luke's point if someone suggests a different transition
strategy based on capabilities that his server does not have; it begs the
question how do we transition to the transition strategy.
Perhaps someone could post details (or a link) explaining how to use multi
on the cern server. Preferably an example of exactly what you have to do to
get a URL MyPage.multi to resolve to MyPage.html3 (sent as text/x-html3) if
the client Accepts text/x-html3 and MyPage.html (sent as text/html) if it
does not.
Also, detailed descriptions of how to get the CERN server to automatically
generate (and cache) HTML 2.0 versions of 3.0 documents if MyPage.html does
not (yet) exist. I presume you use CoST (the Copenhagen SGML Toolkit) and an
incr-tcl script to convert HTML 3.0 maths to <pre> with an ASCII-art
representation of the math, same for tables, and I guess FIG gets converted
to IMG with the caption underneath and the enclosed text thrown away or
extracted into MyPage-FIG1.html or something.
I can see the benefits of such an automatic conversion strategy, and
various people have said it is do-able now, but I and probably others would
appreciate some detailed instructions on how to actually do it in practice.
Actually, I am not convinced that either strategy will work correctly in all
cases; the DOIT stategy will fall foul of partial implementations (such as
tables where <th> is not implemented; to be fair Luke points this out himself) and the
the content negotiation strategy will fail with browsers that Accept: */*
(does that mean that they accept text/x-html3? it seems to. What about
Accept: text/* ?) or that take lax shortcuts when parsing text/* Content-type
headers (such as, if there is a substring match to html assume it is (level 2)
html, otherwise assume text/plain).
> but you should still be able to hack up a CGI script to
> look at the HTTP_ACCEPT envvar).
Don't encourage him!! Anyone that has an IMG on their homepage with SRC
pointing to a CGI script which returns a 302 redirect to a static GIF,
cleverly defeating proxy cacheing, does *not* need encouragement to make
all their pages into CGI scripts! ;-)
> I guess I've run out of energy on this topic. Maybe this is one of
> life's "either you get it or you don't", a fight that can also be
> portrayed as "old guard vs. new energetic upstarts" or "conventional
> wisdom vs. new thinking"
Brian, if it ever gets out that WiReD is a magazine full of conventional
wisdom for the old guard, your sales will plummet ;-)
-- Chris Lilley +-------------------------------------------------------------------------+ | Technical Author, Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------------+ | Computer Graphics Unit, | Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Voice: +44 61 275 6045 | | Oxford Road, | Fax: +44 61 275 6040 | | Manchester, UK. M13 9PL | X400: /I=c /S=lilley | | /O=manchester-computing-centre /PRMD=UK.AC /ADMD= /C=GB/| |<A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +-------------------------------------------------------------------------+ |This is supposed to be data transfer, not artificial intelligence. M VanH| +-------------------------------------------------------------------------+