Authoritative Metadata

In a Finding on "Authoritative Metadata"
(http://www.w3.org/2001/tag/doc/mime-respect), the authors gve the
following guideline for good practice:

"Authoritative metadata SHOULD NOT be provided external to the
representation if it does not add clarity to that communication.

For example, the character encoding of XML data formats is
self-descriptive within the data and SHOULD NOT be included in a charset
parameter of the media type unless that distinction is significant to the
resource (e.g., for comparison during content negotiation of multiple XML
representations that differ only by character encoding)."

On my website, I offer an RSS feed with news and announcements. This feed
is in Dutch, and in utf-8 encoding, so I configured my server to send the
following headers:

Content-Type: application/rss+xml; charset=utf-8
Content-Language: nl

Now this feed is the only feed I offer, so there's not going to be any
negotiation of character encoding or language. According to the guideline
cited above, I should not put these metadata in the HTTP errors, right? Or
should I interpret the phrase "significant to the resource" more
liberally? One could imagine a user agent where the user can configure
which languages he understands. If a user who understands English, French
and Russian tries to subscribe to my feed, the UA first requests the HEAD
for the feed, and based on the "Content-Language: nl" header, it might pop
up a warning like "This newsfeed is in Dutch. Do you really want to
subscribe?" Only if the user says "Yes" does the agent have to request the
complete resource.

The example may be a bit silly, but my point is: why not provide as much
data as possible already in the HTTP headers, even if the same data is
also stored in the resource itself? It's my responsibility as an author to
make sure the metadata given in the HTTP headers are consistent with those
given in the resource itself. What's wrong with doing both as long as I'm
careful to do it right?

--
Garmt de Vries

Garmt de Vries <garmtdevries (AT) googlemail (DOT) com> scripsit:

In a Finding on "Authoritative Metadata"
(http://www.w3.org/2001/tag/doc/mime-respect), the authors gve the
following guideline for good practice:

"Authoritative metadata SHOULD NOT be provided external to the
representation if it does not add clarity to that communication.

I hadn't noticed the existence of such a document. It's labelled "TAG
finding", with an explicit statement: "Publication of this finding does not
imply endorsement by the W3C Membership". Thus, despite using
specification-like language, it's apparently just a consensus of a technical
group, and it has not had a public review or even review by W3C members.

It isn't even clear what it means by "authoritative metadata". There is no
explicit definition, as far as I can see, and they seem to identify
"authoritative" with the presentation of metadata in an "envelope" such as
Internet message headers.

On my website, I offer an RSS feed with news and announcements. This
feed is in Dutch, and in utf-8 encoding, so I configured my server to
send the following headers:

Content-Type: application/rss+xml; charset=utf-8
Content-Language: nl

I see nothing wrong with that, though in practice the latter header will be
ignored.

Now this feed is the only feed I offer, so there's not going to be any
negotiation of character encoding or language.

Negotiation wouldn't take place that way anyway, in practice. It takes place
via _request_ headers, i.e. headers that a browser or other user agent sends
to the server.

One could imagine a user agent where the
user can configure which languages he understands.

No need for imagination; existing browsers are such user agents, though the
configuration methods are awkward and people don't even know about them, as
a rule.

If a user who
understands English, French and Russian tries to subscribe to my
feed, the UA first requests the HEAD for the feed, and based on the
"Content-Language: nl" header, it might pop up a warning like "This
newsfeed is in Dutch.

It might, but things don't work that way. The browser sends an
Accept-Language header, and the server may use it.

The example may be a bit silly, but my point is: why not provide as
much data as possible already in the HTTP headers, even if the same
data is also stored in the resource itself?

Well, I guess you need to read carefully the arguments in the TAG Finding
and perhaps ask the Architecture Group, if the TAG Finding made you feel
uncomfortable. I didn't find any arguments, except the general idea of
avoiding inconsistencies, whatever that means.

It's my responsibility as
an author to make sure the metadata given in the HTTP headers are
consistent with those given in the resource itself. What's wrong with
doing both as long as I'm careful to do it right?

As far as I can see, nothing. I even think that redundancy is good here.
User agents may cross-check different metadata and issue a warning if they
detect a mismatch, which would typically indicate that something went wrong
(e.g., character encoding conversion was performed by a proxy without
changing the internal metadata).

--
Yucca, http://www.cs.tut.fi/~jkorpela/