Re: &http-last-modified; (crazy idea of the day)

Arjun Ray (aray@pipeline.com)
Tue, 19 Dec 1995 17:35:47 -0500 (EST)


Date: Tue, 19 Dec 1995 17:35:47 -0500 (EST)
From: Arjun Ray <aray@pipeline.com>
Subject: Re: &http-last-modified; (crazy idea of the day)
To: Lambert <paumic@ids.net>
Cc: www-html@w3.org
In-Reply-To: <v01530500acfccfdb8ee1@[155.212.70.11]>
Message-Id: <Pine.3.89.9512191605.A8472-0100000@alpha>



On Tue, 19 Dec 1995, Lambert wrote:

> >I like the idea, but the drift I'm getting is that entity names are
> >to be associated with (HTTP) header field names ("Last-Modified" with
> >`&http-last-modified;', "Access-Count" with `&http-access-count;', etc)
> >and that I'm not so sure I like.
> 
> The http looks like a good idea, or maybe &meta-access-count, since they
> ere meta headers, no necessarily by HTML.

No. Unless I completely misunderstood the motivation, Dan was suggesting 
a mechanism to incorporate HTTP header information dynamically into the 
document *after* the transfer has occured, i.e. until then, the HTTP 
header information wouldn't be known. A macro with run-time binding.

At any rate, entities will raise problems with SGML parsers: 

   1. We'll need declarations -- possibly in a DTD subset?
   2. Entity names are case-sensitive, which could get nasty.

Moreover, for parsers in general, why should we assume that a parsing
subroutine/module/subsytem has knowledge of or access to specifics of the 
*transfer* protocol? Requiring the parser to establish the binding to 
essentially run-time information is an unnecessary strong coupling, IMHO.

> Or how about:
>     HTTP/1.0 200 Document Follows
>     Last-Modified: Monday, 11-Dec-95 22:04:32 GMT
> 
>     <title>Arjun's First Reaction</title>
> 
>     <address><field http-equiv="Last-Modified">text inserted by normal
> counters</field></address>
> 
> An old browser would ignore the <field> tags, and use the text and HTML
> beteween them. You could do an old counter tht way. For the newer browsers,
> they would not display the text between the <field> tags, and use the
> original field tag. This would be similar to <NOFRAMES>

In other words, if a "new" browser groks <FIELD>, the content  
"text inserted by normal counters" should be treated as alternative and 
suppressed? The mechanisms in <INSERT> son of <EMBED> son of <FIG> seem 
to cover that kind of functionality, and besides, I'm over my first 
reaction:-)

Scratch my tag idea. Why not a processing instruction?

   <address><?HTTP Last-Modified></address>


Regards,

Arjun