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

On Fri, 15 Dec 1995, Daniel W. Connolly wrote:

> Just a hair-brained idea that I don't want to forget:
> 
> Consider:
> 
> 	200 document follows:
> 	Last-Modified: Monday, 11-Dec-95 22:04:31 GMT
> 
> 	<title>Dan's Hair-brained Idea of the Day</title>
> 	...
> 	<address>
> 	&http-last-modified;
> 	</address>
> 
> displays ala:
> 
> 	Dan's Hair-brained Idea of the Day
> 	...
> 	Monday, 11-Dec-95 22:04:31 GMT
> 
> Other possibilities:
> 
> 	200 document follows
> 	Access-Count: 12312
> 	Access-Count-Since: Monday, 11-Dec-95 22:04:31 GMT
> 
> 	...
> 	This page has been accessed &http-access-count; times
> 	since &http-access-count-since;.
> 
> It's a nifty idea that would save a lot of trouble and automate a lot
> of stuff that folks do, and increse cache effectiveness. 

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.

Fact is, who wouldn't just love parametrizable macros in SGML? :-)

But since we don't have them, and since SGML-aware parsers are going to
spit at undeclared entities, the idea needs a mechanism that's *opaque* to
the parser.  Basically, we need something like <META>, but for
%body.content, or %text, I suspect. Can't think of a nifty name yet,
so let's try FIELD....

    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"></address>

will get the desired effect, provided we have a <FIELD> GI with attribute 
HTTP-EQUIV (NAME and CONTENT also maybe??) and EMPTY content, that can 
appear anywhere character-level markup is allowed.

Pro:

(1) The *name* of the HTTP header field is opaque to the parser.
(2) The parser may not have access to header-info to begin with, but the 
application level surely will.

Con:

(1) Yet another tag ...
(2) I'm sure there are other objections:-)



Regards,

Arjun Ray

Received on Friday, 15 December 1995 15:51:45 UTC