Re: content type for XHTML fragments: reformulated

Garret Wilson <garret@globalmentor.com> wrote:

>Example: "this is <em xmlns="http://www.w3.org/1999/xhtml">really</em> cool"
>
>Context: An application (e.g. a wiki or a newsfeed) might elect to store 
>snippets of XHTML information in independent files, and later assemble 
>these bits of comments into a single XHTML document to present to the 
>browser. Obviously the application must be able to distinguish between 
>plain text files and markup files---otherwise it would be ambiguous 
>whether "this is <em xmlns="http://www.w3.org/1999/xhtml">really</em> 
>cool" should be integrated into the XHTML document as a plain text 
>string (and therefore '<' should be encoded as &lt;, for example), or 
>whether the string should be interpreted as actually defining a 
>hierarchy of XHTML elements.

What the application does with content fragments should be defined by
the application's configuration. It should not be determined by the
content fragment's content-type.

A content fragment (whether it contains markup or not) should not be
served with a (X)HTML document content-type since it is not a (X)HTML
document, only a complete valid (X)HTML document should be served as
such.

The application's handling of the code fragment according to it's
content-type as you suggest makes no sense, it cannot determine what to
do with it based on it's content-type, for example to include it (as
with SSI), or to embed it when served as a (X)HTML document
content-type. Thus it needs to be defined in the application's
configuration.

Content snippets should therefore be served as text/plain, the fact that
the snippet *may* contain markup is irrelevant. The application is the
only tool that should have access to the content snippets, it's
configuration should ensure how the snippet is handled (i.e. included
verbatim without parsing it or doing anything else to it).

-- 
Spartanicus

Received on Tuesday, 17 January 2006 10:09:32 UTC