1. Everything inside the HEAD is metainformation. That's what
the head is for.
2. The relationship beteen elements in the HTML HEAD and the HTTP
headers is referred to in the HTTP spec which suggests allowing
and header WWW-xxx where xxx is an HTML element. For example,
HTTP gains WWW-Link: http://foo/bar rel=whatever by this method.
If we have HTML headers which are defined on HTTP headers, we
will have the dog chasing its own tail fairly quickly.
Suppose we hypothesize that *amything* in an HTML HEAD element
should be expressable in an HTTP header. This is true if anything
about an HTML body can also apply to GIF. In that case, the HTTP
becaomes the master spec to which HTML should refer. It also
suggests that HTTP might have to eveolve faster than HTML.
3. I agree with both camps about how this shouldn't be done!
I don't like the idea of changing a DTD every time someone
wantsto add a new HTTP element, as I can see those elements
becoming very many, and having many headers used only by
local communties (Content-Shelf-Number:, X-Compuserve-Xref:, etc)
Can we have some way of tying them together? How about an
architecural form? Or an attribute?
<EXPIRES http-equiv="expires"> Jan 10,,,</EXPIRES>
This "http-equiv"attribute binds the element to the header.
It means that if you know the semantics of the http header
"Expires" then you can process the contents based on a
well defined syntactic mapping, whether or not your DTD
tells you anything about it. So you can use it with
"META"if really HTML has no use for the element, or
(experimentally, walking in fear of the SGML purists)
with your experimental element name, or when a
element name has been defined, then using the element
name in a new DTD.
I can imagie defining an SGML architecural form which
would allow one to specify that the http-equiv attribute
had this significance in this DTD, though the treatment
of unrecognised headers is something which a DTD can't
even think about.
4. If we have such a mapping, then we have to make sure that
the order of elements in the HEAD has the same significance
as the order of elements in the HTTP headers, which is
(I think) currently notthe case: HTML HEAD specifically
specifies an *unordered* list of meta information,
wheras I bet there are millions of constraints people
have put on the order of RFC822 headers, including for
example that MIME-Version must precede all MIME headers.
5. If we mve toward http headers as the defining point for
metainformation, we are using a syntax which is poor
in structure. This should not worry us. I see no reason
for constaining HTTP headers to be unstructured, so if
we find a need for the odd {bracket} which will of course
map fine onto SGML, we should not be put off.
MIC-header: {
blah:
blah:
MIC-header: }
or whatever.
Tim