Re: content type for XHTML fragments: reformulated

Spartanicus wrote:
> It makes no sense to serve a "foo" content fragment as text/plain and
> "<em>foo</em>" as something else. In the context of a content fragment
> both are just plain text.
>   
You're missing the point. Let's say that the two fragments are not "foo" 
and "<em>foo</em>". Instead, the two fragments are "<em>foo</em>" and 
"<em>foo</em>". The former is a fragment of a web page on XHTML 
explaining how to use the <em> element, and actually displays the 
literal string "<em>foo</em>". The latter, when transcluded into the 
main document, actually displays the word "foo" as emphasized (such as 
using italics). The former is plain text. The latter is an X(HT)ML 
fragment. How does an application know whether "<em>foo</em>" is plain 
text or an XHTML fragment? Not by the characters in the string (because 
both strings have identical characters), but by a piece of metadata 
called the content type.

Your argument, if applied generally, would mean that all text files 
should be served as text/plain---even XML files.

If there is a need for distinguishing content types at the document 
level, there is a need for distinguishing types at the fragment level.

Garret

Received on Tuesday, 17 January 2006 19:48:38 UTC