Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments)

[Asbjørn Ulsberg]

On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy <[EMAIL PROTECTED]>  
wrote:

<atom:content type="XHTML" xmlns:atom="our namespace URI" xmlns="XHTML's  
namespace URI">
<div>This is XHTML content,<br />
and the default namespace is XHTML's.</div>
</atom:content>
This example made me think about another solution for the Content  
Constructs of Atom. Today, they all reside in the Atom namespace, which of  
course, makes most sense. But even though I see it is a major hack, won't  
putting Content Constructs inside the target namespace of the embedded  
content be a solution to tell what type of content we are embedding  
without having to use a 'type' element? Example:

  <feed xmlns="atom ns">
    ...
    <content xmlns="http://www.w3.org/1999/xhtml";>
      <h1>Booyah! This is an XHTML fragment.</h1>
    </content>
  </feed>
Since Atom consumers need to have special handling for each 'type'  
('html', 'xhtml', 'text') we provide today, we might as well imho signify  
this with the XHTML namespace as with a 'type' attribute. The problem is  
that it's difficult to say «this is to be parsed as escaped SGML» in  
contrary to «this is to be read as plain text». Alas, we need a solution  
for non-XML types in Atom if we think using namespaces is a good enough  
solution for XML types.

If we take the hack even further, we could create pseudo namespaces for  
text and HTML types as well. Or perhaps even a general SGML namespace. So  
when we want to embed text in Content Constructs, we do it like this:

  <content xmlns="atom ns#text">
    *Booyah! This is an text fragment.*
  </content>
And when we want to embed HTML, we do it like this:
  <content xmlns="atom ns#html">
    &lt;h1&gt;Booyah! This is an text fragment.&lt;/h1&gt;
  </content>
I've already mentioned that I think this solution is a hack, and I'm not  
sure I like it, but what I do like about it is that it gives us a general  
way to deal with XML content that is much simpler (imho at least) than any  
other previous solution (which have included 'type', 'mode' and various  
other attributes).

Yes, there is no element called 'xhtml:content' in the XHTML  
specification, but we won't have _valid_ (although wellformed) XHTML in  
Atom anyways, so why strive so hard to reach something we won't reach  
anyway? The XHTML content in Atom will be valid XML. It can't ever be  
valid XHTML. Let's just settle with that and move forward, no?

--
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»