Website Design Forum - Authoritative Metadata

Author

Authoritative Metadata

Garmt de Vries

2006-05-23, 7:03 pm

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 th=
e =

resource (e.g., for comparison during content negotiation of multiple XM=
L =

representations that differ only by character encoding)."

On my website, I offer an RSS feed with news and announcements. This fee=
d =

is in Dutch, and in utf-8 encoding, so I configured my server to send th=
e =

following headers:

Content-Type: application/rss+xml; charset=3Dutf-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 guidelin=
e =

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, Frenc=
h =

and Russian tries to subscribe to my feed, the UA first requests the HEA=
D =

for the feed, and based on the "Content-Language: nl" header, it might p=
op =

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 t=
he =

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 tho=
se =

given in the resource itself. What's wrong with doing both as long as I'=
m =

careful to do it right?

-- =

Garmt de Vries

Jukka K. Korpela

2006-05-23, 7:03 pm

Garmt de Vries <garmtdevries@googlemail.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/