A. Pagaltzis wrote:
* James M Snell <[EMAIL PROTECTED]> [2005-08-25 08:35]:
I don't really want aggregators pulling and indexing that feed
and attempting to display it within a traditional feed reader.
Why, though?
There’s no reason aggregators couldn’t at some point become more
capable of doing something useful with unknown content types (cf.
mail clients), and even before, subscribing in an aggregator is a
useful debugging venue in a cinch.
I think what you need is no more than a way to say “this doesn’t
contain human-readable content.” I don’t know that I’d try to put
this fact into the feed in machine-readable form. I’d be inclined
to just supply an atom:subtitle for the feed saying that there’s
nothing to read here, sorry.
Good points but it's more than just the handling of human-readable
content. That's one use case but there are others. Consider, for
example, if I was producing a feed that contained javascript and CSS
styles that would otherwise be unwise for an online aggregator to try to
display (e.g. the now famous Platypus prank...
http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).
Typically aggregators and feed readers are (rightfully) recommended to
strip scripts and styles from the content in order to reliably display
the information. But, it is foreseeable that applications could be
built that rely on these types of mechanism within the feed content.
For example, I may want to create a feed that provides the human
interaction for a workflow process -- each entry contains a form that
uses javascript for validation and perhaps some CSS styles for
formatting. Such a feed would likely require authentication to access,
so maybe that is enough? I dunno, I'm just kinda scratching my head on
this wondering if there is any actual need here. My instincts are
telling me no, but...
- James
