[...] If it's an xml file, doesn't that already imply the the content- type is xml?
This is circular logic ;)
I agree :) How can you have a content-type specification instruction which tells the processor what content-type this document is? ie. <meta http-equiv="Content-Type" content="application/pdf; charset=utf-8"/> doesn't make any sense.
Also, we want to further specialize the type, i.e. it could be xhtml +xml (as in this case) or it could be rss+xml, that is what we need to specify.
Does rss+xml have a <meta> tag?
Isn't the content only important when you're sending things "over the wire" so the program at the other end can recognise what to do? The meta tag is just a hack for html to give the page author some way of overriding the content-type that the server is sending.
I don't fully follow this. But the meta tag is not a hack, it is a way to specify the content type (and encoding, etc.) when the page is NOT sent over http, i.e. when it is loaded from a non-http server (like your disk drive). The meta tag never overrides the info sent by the server, on the contrary, it is the server which overrides the meta tag.
see above, and links in the other email I sent. I'm not sure that this is the full story.
There's a good discussion of xhtml here: http://www.hixie.ch/ advocacy/xhtml. I think this sums it up: [...]
Sure, XHTML is not useful on the net, etc. -- but what we are discussing here is how a correct XHTML 1.1 template should look, regardless of what the real-life treatment of XHTML for content sent over http is.
Fair enough.
Hadley