Re[2]: Content negotiation

     unsubscribe


______________________________ Reply Separator _________________________________
Subject: Re: Content negotiation
Author:  www-talk@w3.org at interport
Date:    11/9/95 12:34 PM


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 problem.
     
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
  sjk@amazon.com

Received on Thursday, 9 November 1995 12:57:58 UTC