Re: content type for XHTML fragments: reformulated

It's been a while since this thread ceased being active, but I've been 
thinking of a more elegant way of transferring chunks of XHTML between 
applications/documents. This could eventually be added to XHTML 2.0.

My proposal is to add a <fragment/> root element that encapsulates the 
XHTML content being sent. That way you could send that content as 
application/xhtml+xml.

Instead of
  This is <em>really</em> cool
or
  <span xmlns="http://www.w3.org/1999/xhtml">This is <em>really</em> 
cool</span>

You could write
  <fragment xmlns="http://www.w3.org/1999/xhtml">This is <em>really</em> 
cool</fragment>

Which would allow the receiving application to make qualified decisions 
and maybe even validate the XHTML.



Cheers,
Daniel Schierbeck


Garret Wilson wrote:
>
> There has been a bit of confusion about this question, so let restate 
> succinctly the query.
>
> Question: What content type should be used for XHTML fragments stored 
> independently of any XHTML document?
>
> 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.
>
> Relevance to www-html: RFC 3236, "The 'application/xhtml+xml' Media 
> Type" ( http://www.ietf.org/rfc/rfc3236.txt ), clearly states, "Please 
> send comments to www-html@w3.org...." (section 1). This is not a "how 
> to" question, but a "which one" question.
>
> Related Text from RFC 3236:
>
>    With respect to XHTML Modularization [XHTMLMOD] and the existence
>    of XHTML based languages (referred to as XHTML family members)
>    that are not XHTML 1.0 conformant languages, it is possible that
>    'application/xhtml+xml' may be used to describe some of these
>    documents. ...
>
>    Although conformant 'application/xhtml+xml' interpreters can
>    expect that content received is well-formed XML (as defined in
>    [XML]), it cannot be guaranteed that the content is valid XHTML
>    (as defined in [XHTML1]).  This is in large part due to the
>    reasons in the preceding paragraph. (section 2)
>
> Possible Responses:
>
> * Use "application/xhtml+xml", because this content type can be 
> applied to XHTML content that does not constitute a complete XHTML 
> document---but wrap the fragment in an outer element such as "<span 
> xmlns="http://www.w3.org/1999/xhtml">this is <em>really</em> 
> cool</span>".
>
> * Use "text/xml" or "application/xml" and wrap the fragment in an 
> outer element.
>
> * Use "application/xml-external-parsed-entity" and wrap the fragment 
> in an outer element.
>
> Is there no specification that defines the content type of an XHTML 
> fragment? XHTML requires an <html> element for XHTML documents, but it 
> seems to me that a "marked-up XHTML string that is not an XHTML 
> document" is a very common use case. Therefore so it's necessary to 
> determine what the standard content type would be for such an XHTML 
> fragment.
>
> Garret
>
>

Received on Sunday, 29 January 2006 12:38:18 UTC