> 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