______________________________ 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