I much prefer www-talk because it has the nifty hypertext archive...
I second the "www-developers" idea.
>>
>>Good. Examples. I love examples. As a counterexample, consider:
>>
>> <EXPIRES DATE="Tue, 04 Dec 1993 21:29:02 GMT">
>
>That's fine, but it assumes that the server/tool knows the syntax of
>the EXPIRES element. The META element allows any name-value pair to
>be expressed (and thus parsed) without knowing the purpose of that
>name or value. We can then add new names without changing the spec
>and all implementations of the servers.
Hmmm... I don't think I get the point here. The EXPIRES element follows
the syntax of an SGML tag. There is a long-standing convention that
tags can be parsed and discarded if they aren't recognized.
So we can already add new names "...without changing the spec and all
implementations of the servers."
Now granted, those new names don't _do_ anything. But I don't see how
you expect to be able to add new features without changing any code.
We already saw that the server must carefully inspect these names
before turning them into HTTP headers, for example.
>> 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?
>
>No. There is a substantial difference between a public agreement (which
>may include only a small subset of webspace) and general consensus, and
>even when they do coincide there is generally too long of a lag time between
>the need and the spec and then also between the spec and the implementation.
I agree that maintenance of the spec is an issue. Let's not let that
influence the design of the language too much.
>>> 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.
>
>If this were true with the current implementation of HTML, then I would
>agree and we could all get on with our work without any need for the META
>element. If the HTML 2.0 spec is written such that <HEAD></HEAD>
>and <BODY></BODY> are required and explicit instructions are included
>that browsers not render anything within <HEAD>...</HEAD>, and then all
>offending browsers are fixed accordingly, then we can talk about using
>any element name within the HEAD as a response header.
Bingo. In my interpretation, this has been in the spec all along. I'll
certainly make it more clear in future revisions. Though I wouldn't
word it _quite_ that strongly: a browser may present things like TITLE
and the Last-Modified HTTP header to the user. But these are distinct
from the BODY information flow.
>If you don't want to require that in HTML 2.0, then we are stuck with using
>META since it is the only way to provide such information across different
>versions of HTML -- a necessary requirement for my application.
Let us not let broken implementations influence the language design
too much...
>One question I have regarding use of HTML element names as headers is what
>are the character limitations on element names? From the DTD they appear
>to be close enough to rfc822 contraints, but is 34 characters the actual
>length restriction or just a uniqueness restriction (or am I misreading it)?
The syntax of a name is: a letter followed by letters, digits,
periods, and hypens. The 34 character limit is SGML wierdness #756.
All HTML documents share an SGML declaration. That declaration has
to pick a number for the maximum length of a name. (The default is
8!). 34 comes from DocBook, or one of IBM's DTDs, or something -- it's
almost completely arbitrary. There's no way to express "names may have
unlimited length" (though there may be in a future revision of the
SGML standard, I understand). We can pick any number up to around 254,
at which point certain tools (like sgmls) start to break.
If we changed it to 72, that would certainly be enough for any RFC822
header name. Perhaps that's a good idea.
>> No, and I'm not trying to. New elements can and will be added over time.
>
>How??? It is not good enough to say that they will be added -- there needs
>to be a specific mechanism defined whereby they can be added without breaking
>existing implementations. We can't define a new content-type every time
>we need a new element.
As precedents, look at IMG, HR, BR.
Dan