[Catalyst] [Announce] Planet Catalyst

[A. Pagaltzis]

* Jonathan Rockway <jon at jrock.us> [2006-08-06 23:40]:
> Hmm, how well supported are XML namespaces by RSS readers? I'd
> really like to do something like this:

They’re almost universally compliant when parsing, but few manage
to pass document fragments to their HTML rendering component with
namespaces intact.

See also:

    Xml Namespace Conformance Tests
    http://intertwingly.net/wiki/pie/XmlNamespaceConformanceTests

> <content xmlns:h="http://www.w3.org/TR/1999/xhtml"
>                  xmlns:s="http://the.svg.spec/foo/bar/baz">
> <h:body><h:h1>This is a post, yay.</h:h1><h:p>Paragraph</h:p>
> <s:svg><!-- uh oh, we've embedded a picture --></s:svg>
> <!-- and so on -->
> </content>
> 
> This seems like The Right Way To Do Things; no dealing with
> mime types or anything, all the content is properly encoded in
> the XML.

This is invalid. It violates two to four different constraints,
depending on how you count.

• Omitting the `type` attribute on the `content` means you want
  to default to `type="text"`, in which case there must be no
  child elements in `content`.
  
  Obviously that’s not what you meant. Since you want to include
  XHTML unescaped in your feed, you can use either `type="xhtml"`
  or `type="application/xhtml+xml"`.

• If you put `type="xhtml"` on the `content` element, you fail
  validation because then the *ONLY* child of the `content`
  element MUST be a `div` element in the XHTML namespace, not a
  `body` element. I assume that you would replace the `body`
  element with the `div` – if you keep the `body` within the
  `div`, that would be an invalid XHTML fragment.

• If you use `type="application/xhtml+xml"`, then it must be a
  complete XHTML document. What you have there is not complete;
  it needs at least a `html` element.

Your best bet is to read the spec: RFC 4287. It’s long and not
exactly a thrilling novel, but as specs go, it’s very readable
and not that long at all.

In short, to be valid, and keeping in mind that relying on the
default namespace is your only good bet to get namespaces to the
HTML rendering component unmangled, what you want to do is this:

    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <h1>This is a post, yay.</h1>
        <p>Paragraph</p>
        <svg xmlns="http://www.w3.org/2000/svg">
          <!-- uh oh, we've embedded a picture -->
        </svg>
        <!-- and so on -->
      </div>
    </content>

I would *love* to be able to do the following:

    <!-- at the top of the feed: -->
    <a:feed
      xmlns:a="http://www.w3.org/2005/Atom"
      xmlns:s="http://www.w3.org/2000/svg"
      xmlns="http://www.w3.org/1999/xhtml">

        <!-- later... -->
        <a:content type="xhtml">
          <div>
            <h1>This is a post, yay.</h1>
            <p>Paragraph</p>
            <s:svg>
              <!-- uh oh, we've embedded a picture -->
            </s:svg>
            <!-- and so on -->
          </div>
        </a:content>

      <!-- ... -->

    </a:feed>

As you can see, this would mean declaring the namespaces once and
only once at the top of the feed, choosing the XHTML namespace as
the default one throughout the document, since most elements in a
feed document are in that namespace. This arrangement is maximally
parsimonious with filesize.

Unfortunately, a sizable portion of aggregators chokes on it:

    Who knows an XML document from a hole in the ground?
    http://plasmasturm.org/log/376/

> Of course there should be XLinks to the relevant style sheet,
> as well.

I bet the support coverage for that sort of thing is precisely
0%.

Forget CSS in your feeds anyway – most aggregators filter it out
pretty aggressively because of the potential for abuse.

You *shouldn’t* even want it – I use an aggregator to read feeds
precisely because there is no “design” in them, just pure
unadulterated content, and most aggregator users feel the same
way.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>