Re: meta information

A few points on this topic.

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

Received on Sunday, 5 June 1994 21:37:09 UTC