W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: Content negotiation

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 9 Nov 1995 09:03:45 -0800
Message-Id: <199511091703.JAA04506@bert.amazon.com>
To: hedlund@best.com (M. Hedlund)
Cc: www-talk@w3.org
M. Hedlund writes:
 > At 8:23 PM 11/8/95, Shel Kaphan wrote (quoting me):
 > > > Does "browser capabilities" == "HTML tags and attributes recognized"?
 > >
 > >It certainly *includes* that, but it also includes information
 > >that has to do with the way the browser chooses to render, and
 > >possibly other subtleties I can't think of at the moment.
 > Okay, I think this is an important point.  I was saying before that "the
 > way the browser chooses to render" should be left out of this discussion
 > and reserved for style sheets.  If there are other subtleties that are not
 > properly style-sheet problems, let's here about them.

This further subdivides into two categories: (a) browser peculiarities
that are constant properties of the browser (+ version + platform),
and (b) more dynamic browser "choices" that can vary (due to user
control or configuration) from one instance to another.  I think that
(a) needs to be encompassed to say we have a complete solution to this

As examples, does the browser always break the line on </form>?
How does text flow around images?  These properties are not going to
be found in a formal description, but they can be relevant to
the way a server wants to render pages.

 > > > If so, can't we just derive this information from DTD's[1]?  DTD's already
 > > > exist for Mozilla and Hotjava -- see <URL:http://www.halsoft.com/html/>.
 > >
 > >That seems like a good idea, and as has been mentioned before, the
 > >URL of such documents could be made available to servers, though I
 > >kind of like not having to go find a document out there in hyperspace,
 > >where it might not be found reliably, etc.
 > I certainly agree, but URLs change.  The URL of the DTD seems better
 > reserved for "Release Notes" or the like -- do we really need that URL in
 > every request from this browser?  The idea of using the DTD identifier was
 > to provide a lasting reference, one that could be archived long after the
 > MyBrowser project is abandoned or whatever.  Also, that identifier maps
 > directly to the DOCTYPE tag that should be at the top of each HTML
 > document, so everyone's using the same identifiers.

I don't get this.  Are you saying that there is a universal repository
of DTD's out there somewhere?   If you don't have the description, you
have to get it *somewhere*, don't you?

And no, I don't think any of this kind of information should be sent
on every request.  I already proposed one method, using the existing
Redirect machinery, for servers to "request" this information from clients.

 > >It also seems like it
 > >might be simpler to have a summary available that is more relevant to
 > >the task at hand than to have to have a SGML parser the server
 > >software, which is, I presume, what it would take.  A list of
 > >(attribute, value) pairs ought to do adequately, and would be really
 > >simple to parse.
 > Wouldn't the DTD itself contain more useful information (this contains
 > that, etc.)?  In any case, who gets to parse the DTD is a detail -- I'm
 > trying to narrow the complaints about content negotiation to a workable
 > area.  The question is:
 >         Would a DTD describing experimental HTML tags provide
 >         enough information for fine-grained content negotiation?

I think not, nor would the DTD + a style sheet containing, I presume,
preferences and configuration options.  An additional set of properties
describing the hardwired rendering choices the browser makes is also needed.
(If you want a complete solution, that is).

 > M. Hedlund <hedlund@best.com>

--Shel Kaphan
Received on Thursday, 9 November 1995 12:23:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC