Re: content type for XHTML fragments

Am Montag, 16. Januar 2006 19:55 schrieb Spartanicus:
> Btw, despite the loose nature of this particular w3 list, this "How do
> I" topic is imo off topic for www-html and should be moved to a more
> appropriate public place.
1. Where to discuss?

I disagree. I do not think this is a "How do I" topic. I think the content 
type for XHTML, or even better, any XML-based document type's fragments is of 
fundamental and general nature. Depending on the continuation of this 
discussion, even an RFC might evolve. And because the whole HTML/XML document 
stuff is nearly completely and the related content type stuff partly more or 
less officially delegated from the IETF/IRTF to the W3C, and because XHTML 
will probably be the most frequent use case of this issue, I think that this 
is the appropriate list.

In short: I would like to see this discussion to continue here on this list. 
Also, this is the first discussion that I follow for a long time - and most 
discussions during the past 12 months were much more of "How do I" topic 
nature than this one.

I completely agree with Björn Höhrmann who wrote:
> application/xml-external-parsed-entity is suitable for any normal XML
> fragment, in particular if the elements in the fragment don't properly
> declare the right namespace(s). 
2. Suggesting application/xhtml+xml-external-parsed-entity
The issue with this content type is that it does not carry any information 
about the namespace or semantics.

A possible content type could be application/xhtml+xml-external-parsed-entity.
The problem with that content type is that it is not official. So DON'T USE 
THIS!
But the idea could be to take xml document fragments into account when 
defining future RFCs for content types of XML-based message entities.

3. Issues for */*+xml-external-parsed-entity
A question arises about what to do when the content type is not from the 
application/ mime type space, for instance if it is image/svg+xml. Should it 
be application/svg+xml-external-parsed-entity or 
image/svg+xml-external-parsed-entity? In that case I'd vote for application/ 
because I'd treat the renderability as a requirement for types in the image/ 
namespace, and fragments of SVG are unlikely to be renderable. But it might 
not always be so easy to decide as in the case of SVG.

4. application/xhtml+xml requires well-formedness
The point about application/xhtml+xml is that it doesn't neccessarily need to 
be a valid document from the XHTML namespace, but it definitely should be 
well-formed XML.

5. Do XHTML fragments need to be well-formed?
The answer whether XHTML fragments need or need not to be well-formed depends 
on the context. The MIME Type is a part of this context. If the MIME Type 
used leads to the conclusion that it refers to an XML document, and that's 
the case for application/xhtml+xml, receivers will expect well-formedness.

6. Recommendation for now
So for now, I would recommend to use application/xhtml+xml for well-formed 
XHTML fragments, application/xml-external-parsed-entity for XHTML fragments 
that are not well-formed themselves but will lead to a well-formed result 
when parsed in their context.

7. Whether to escape X(HT)ML content in XML context
This depends on the purpose. But if you use XHTML fragments in XML context, 
escaping answers the question whether to use a MIME Type at all.
MIME Types are for message bodies. An unescaped XHTML fragment inside an XML 
document I think cannot be interpreted as message body. So MIME Types would 
be the wrong document kind selection - XML namespaces should be used instead.
If it is escaped, then MIME Types are okay and XML namespaces are wrong 
(unless they are escaped as well).

-- 
Christian Hujer
Free software developer
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/ http://daimonin.sf.net/

Received on Tuesday, 17 January 2006 18:36:20 UTC