Some very good points. I'll address one side of the problem here.
The main missing feature I think is that clients don't currently have any
way to specify what format you want. It would also be extremely helpful
if clients had some way to ask the server what formats it is able to
provide for a given document. This could be done with HEAD by adding a
new object header:
Formats: text/plain,text/html,application/postscript
This is just off the cuff.
Once it's in place then providers would not waste their time doing it
manually (nobody *wants* to put multiple links for the same data).
Sadly this could take a long while to become standard. The WWW is a victim
of it's own success here.
The server part of this doesn't have to be very complex.
> [First, I wish all the _here_'s would go away, but that's another
> story altogether.]
Amen! And the "Click"'s also.
> I'd actually say that the Mcom extensions are less worrisome than tables:
HTML with tables should not be called text/html, it should be something
like ``x-html-tbl''. As I previously posted it will be nigh impossible
to sort out dozens of different independent formats (tables, math, figures,
etc) collected under a single text/html umbrella. It will never fly.
> Ideally, the server would convert the table to PRE or some such.
If both formats weren't called "text/html" then the server could do that
without too much trouble (kind of like Plexus does with Setext -> HTML).
> 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.
More importantly I think is that we have to make it easy for
users to select the format of their choice.