> >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