[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] shared feed lists



Now, as to the meat of the data to be contained at the indicated URL I'd like to
suggest that it offer some things

Use of OPML for this is going to be needlessly limiting.

Right now that format forces everything to be an attribute.  For something like
an text outliner it's a fine way to do things.  But for something like feed
lists it's more limiting than is useful.

I'd like to propose that the format consider containing per-reader information.

Something like: (and this is entirely off the top of my head)

<feedlist rdf:about="http://example.com/this-docs-url.xml";>
    <channel rdf:resource="http://example.com/some/feed.xml/>
    <channel rdf:resource="http://example.com/a/feed.xml/>
    <channel rdf:resource="http://example.com/b/feed.xml/>
    <channel rdf:resource="http://example.com/c/feed.xml>
          <dc:created>2002-06-11T18:30:00Z<dc:created>
          <dc:modified>2003-10-14T11:30:00Z<dc:modified>
    </channel>
    <!-- or perhaps use opml style feed links but suffer their limitations -->

     <reader rdf:ID='homeReader'>
               <app rdf:resource="http://www.feeddemon.com/"/>
                <dc:created>2003-06-11T18:30:00Z<dc:created>
                <dc:modified>2003-10-14T12:30:00Z<dc:modified>
                <feeds>
                    <channel rdf:resource="http://example.com/some/feed.xml>
                        <lastRead>2003-10-14T12:30:00Z</lastRead>
                     </channel>
                     <!-- N+ number of channel elements -->
                </feed>
       </reader>
        <!-- N+ number of reader elements -->
</feedlist>

What this would offer would be a way for this document format to be used not
only as an oversimplified index of the feeds but also as a way to syncronized
local readers with each other.  As in, use this as a way to upload/download
between your reader program at the office with the reader program at home, on
your laptop, on your PDA or whatever.

OPML, as it's designed, forces the developers into using what will turn out to
be a horrible mishmash of attributes.

Now, while I use RDF in the above example, and it's got a number of quite handy
ways to make things very compact, I'm not fixated upon it.  Using it does end up
making a lot of sense but that's a different argument.

Now, this is /much/ broader in scope than a simple site list.  But I'd argue
that instead of pushing OPML in this manner it'd be more useful, in the long
run, to open the door to a much more extensible format.  It's not like there's
some horrible rush needed here.  So why hurry a half-baked solution to market
and then suffer the hassles of legacy difficulties?

-Bill Kearney
Syndic8.com