W3C home > Mailing lists > Public > www-tag@w3.org > August 2006

Re: Approved TAG finding: Authoritative Metadata

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 9 Aug 2006 02:51:49 +0000 (UTC)
To: noah_mendelsohn@us.ibm.com
Cc: Anne van Kesteren <annevk@opera.com>, www-tag@w3.org
Message-ID: <Pine.LNX.4.62.0608090222170.5340@dhalsim.dreamhost.com>

On Tue, 8 Aug 2006 noah_mendelsohn@us.ibm.com wrote:
> I hope it's clear that my note wasn't questionning anyone's motives or 
> level of effort, least of all yours.

Oh I didn't think you were questioning my motives, don't worry! I just 
thought I should give some background for my blog post lest people think I 
was just criticising from the sidelines or something.

> I also think that the Web will be much better off if starting now, those 
> who deploy resource, and particularly those who deploy new media types, 
> new sorts of client side references (e.g. the next thing that plays the 
> role of <img>) try to learn from the TAG finding and do things "right".

Yes, I agree that would be nice (to put it mildly). But why would it 
happen for future MIME types when it hasn't happened for the previous 
ones? It's not like using Content-Type is a new idea, or that people 
previously didn't realise that there were big problems if you ignored the 
file's labelled type.

Say a new format comes along for describing 3D annotations to planetary 
models. Lots of people put up these files -- let's call them KML files for 
the sake of argument -- on their Web sites, in e-mails, on their file 
systems, etc. Many servers don't yet know about these "KML" files -- least 
of all the popular ones like Apache or IIS. Now, all the browsers just 
bail out when they see a "KML" file, saying "I don't know how to handle 
this kind of file!". Then one day, the browsers start supporting them. 
Half the files are mislabelled and don't work with these new browsers, the 
other half work fine. One day one vendor realises it can get a leg up on 
the other browser by making _all_ "KML" content work with their browser, 
instead of just making the correctly labelled subset work. Users start 
asking the second vendor why their browser doesn't work as well.

How do you propose to stop vendors from competing with each other by 
making their user experience better? There is clear historical evidence 
that vendors will ignore standards when the standards get in the way of 
the user experience. Making them feel bad about breaking the specs doesn't 
stop this (believe me, I've tried).

> At least then, we'll be able to gradually start getting the benefits of 
> server-side typing.  The drawback of appearing to deprecate Content-Type 
> is that it misses the opportunity to send a strong admonition that, at 
> least starting here, we're going to try and do things right.

I guess I thought that's what we were doing these last 16 years. I don't 
understand what the TAG finding says other than reaffirming something that 
has had nomative status since long before I looked at the Web.

IMHO we're going to need something a heck of a lot more effective than a 
TAG finding to actually have any effect here.

The biggest thing I'm worried about here, to be honest, is that every time 
we (the standards community) require the browser vendors to do something 
that they consider makes their user's life harder, they get one step 
closer to ignoring _all_ standards. That is, it's not just that they pick 
and choose the standards they want to comply to -- there comes a point 
where engineers decide that they've had enough of "stupid specs" in 
general, and ignore all of them. At that point, we (the standards 
community) might as well go home, because we are utterly powerless without 
the engineers listening to us and doing what we tell them to.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 August 2006 02:52:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:13 UTC