Good. Examples. I love examples. As a counterexample, consider:
<EXPIRES DATE="Tue, 04 Dec 1993 21:29:02 GMT">
> as part of the HTTP response to a GET or HEAD request for that document.
> When the HEADER attribute is not present, the server should not generate
> an HTTP header for this metainformation; e.g.
>
> <meta name="IndexType" value="Service">
Counterexample:
<?indextype service>
> would not generate an HTTP header but would still allow clients or
> other tools to make use of that metainformation.
How would they make use of that information? Unless and until there's
a public agreement about what such data represents, you're talking
about private techniques. When such general consensus is reached,
then we add it to the spec. No?
> Other likely names are "Keywords", "Created", "Owner" (a name)
> and "Reply-To" (an email address).
Yes... all these belong in the <HEAD>...</HEAD> of an HTML document.
The HEAD is by design isomorphic to the HTTP headers, or the headers
of a mail message or a news article. You don't need an extra META
element to say this.
>> What is the meaning of the META element? I've heard several
>> things:
>>
>> Proposal: It's for http headers:
>> <META name="Expires" value="Tue Aug 12, 1994 10:33:32 CST">
>> Answer: Then why not write:
>> <HTTP-HEADER name="Expires" ...>
>Because metainformation may or may not also be useful as header information,
>depending on the capabilities of a given server and the existence of
>future tools which make use of that information. Nevertheless, it is still
>metainformation whether or not it is used within response headers.
I would still like to see a definition of this term "metainformation."
You might say that the TITLE of a document is metainformation. You
might say ADDRESS is metainformation. But I don't see how this distinction
is useful.
>> I can see the need for:
>>
>> <EXPIRES DATE="...">
>>
>> but not a general HTTP header escape mechanism.
>
>But can you anticipate the needs of everyone?
No, and I'm not trying to. New elements can and will be added over
time.
> My original proposal called
>for an EXPIRES element like the above and an OWNER element like
>
> <OWNER name="...">
>
>It was shot down because it does not satisfy the general need for document
>metainformation which can be parsed without pre-knowledge of the purpose of
>that metainformation.
I find that original proposal quite on target, and I don't see how
the counterargument carries much weight. What examples motivate
this "general need for document metainformation" that are not
satisfied by new HEAD elements?
> To take an example from an earlier discussion:
>
> <META name="IAFA-Template" value="document">
>
>would be useful for automated tools that build IAFA indices.
Okie dokie, but why not write:
<IAFA-Template name="document">
>> Proposal II: It's for private indexing techniques. Then why not
>> use comments or processing instructions?
>> <?keywords a,b,c,d>
>> <?description lksjdflkjsdf>
>> or
>> <!-- @#@# KEYWORDS: a,b,c -->
>> <!-- @#@# DESCRIPTION: ... -->
>
>Because it is not for PRIVATE indexing techniques.
This is news to me. What is this public agreement about how these
indexing techniques work? I can imagine some sort of relational
database abstraction behind it all or something... hmmm...
> There is a multitude
>of uses for this information, most of which I did not think of when the
>META element was originally proposed.
In how many cases is this information exchanged between parties, vs.
the number of cases when it is only used privately by one party?
>> As long as these techniques are private to one implementation, this
>> is all you need. If you get to the point where you expect other
>> folks to understand the meaning of these idioms, just propose
>> new tags:
>> <KEYWORDS>a,b,c,</keywords>
>> <description>lkjsdlfkjsldf... </description>
>
>Love to, but HTML lacks any ability to add new elements which
>contain content without breaking compatibility with existing browsers.
Sad but largely true: HTML is defined by the behaviour
of Mosaic. The HEAD element has long been documented as info
that doesn't go in the text flow with the body elements, but
the Mosaic code doesn't make any distinction between HEAD
and BODY.
>Thus, including the above in any existing document will result in the line
>
>a,b,c,lkjsdlfkjsldf...
>
>appearing at the top of the display.
Ok, fine... so make all the new elements empty. Or just fix Mosaic. :-)
>> And about indexing... anybody who's interested in these problems should
>> probably try to follow the discussions about URC's on the
>> [email protected] mailing list.
>
>Is that a person or a mail robot? It did not respond to my request yesterday.
Dunno about administrivia of the list.
>Is that discussion archived on the web?
I think so... yup...
http://www.acl.lanl.gov/URI/archive/uri-archive.index.html
>> Also, at WWW '94, it was suggested that the TEI header might be a workable
>> technology to use in this area.
>
>It was? Could you elaborate?
Stu Wiebel from OCLC said he'd been looking at the TEI header
as a URC mechanism. Several other folks nodded and grunted.
I haven't looked closely at the TEI stuff yet, so I can't
say much more...
>The META element is not a hack.
I disagree.
Dan