Re: content type for XHTML fragments

Christian,

Christian Hujer wrote:
> 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). 
>>     
> [cut]
> The issue with this content type is that it does not carry any information 
> about the namespace or semantics.
>   
I agree---it would be useful for the application to know ahead of time 
if the XML snippet contained an XHTML fragment, a Docbook fragment, a 
TEI fragment, or what, especially in the case of vocabularies that do 
not have defined namespaces.
> A possible content type could be application/xhtml+xml-external-parsed-entity.
>   
Ooh, I like it!
> But the idea could be to take xml document fragments into account when 
> defining future RFCs for content types of XML-based message entities.
>   
You mentioned the possibility of a new RFC earlier, which I'm completely 
game for. Let's continue to discuss this, keeping in mind such a 
possibility.

> 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.
>   
I suppose that is a broader issue, but one that perhaps we could 
postpone for now. RFC 3023, "XML Media Types", which defines the "+xml" 
convention, seems to allow either text/ or application/ based upon the 
context. I'd say that as a rule of thumb the fragment content type 
should follow the non-fragment content---in other words, a fragment of 
image/svg+xml should be image/svg+xml-external-parsed-entity. But again, 
that's probably something we can postpone or even leave open.

> 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.
>   
That seems so, but RFC 3023 seems to be unclear on whether */*+xml 
documents should be well-formed. On the one hand the "+xml" suffix is 
defined "for identifying XML-based MIME media types, whatever their 
particular content may represent" (section 7, page 15). According to RDF 
3023, XML MIME entities seems to include 
application/xml-external-parsed-entity (section 3, page 4).

But although RFC 3023 indicates that that an area of "generic" 
processing that is useful is "Fragment identification", the "+xml" 
convention is supposed to "allow applications that can process XML 
generically to detect that the MIME entity is supposed to be an XML 
document, verify this assumption by invoking some XML processor, and 
then process the XML document accordingly." (section 7, page 16) 
Generically processing a "+xml" entity as XML doesn't seem to apply to 
application/xml-external-parsed-entity.

In short, it seems that RFC 3023 overlooked a convention for 
application/xml-external-parsed-entity analogous to "+xml". I think your 
proposal for "+xml-external-parsed-entity" addresses this oversight, and 
I'd be willing to work with you on an RFC to follow up RFC 3023 
outlining this recommendation, if we decide it's appropriate.

Garret

Received on Tuesday, 17 January 2006 19:35:20 UTC