Some of the categories of use cases are:

RSS Original Sources

• authors using text or simple XML editors
• authors using "smart" XML editors
• RSS generated by a user-chosen tool (eg. XML::RSS)
• RSS generated by the hosting site/software (eg. Manila, eGroups)
• See the RSS Info list

RSS Middleware

• aggregators
• distributors

RSS clients, renderers, and applications

• server sites (my.*)
• local generated home pages
• RSS meta-data engines (queries, catalogs, etc.)
• special-purpose apps (eg. RSS-on-desktop/toolbar, tickers)
• See the RSS Info list

Some of the types of tools used for the above:

Generic RDF Libraries

• may or may not have access to schema information
• may not preserve or output RSS-required typed-element format
• provide techniques for resolving repeated statements
• very "loose" at the library level
• (need specific list of tools)

Generic RSS libraries

• may or may not have access to schema information
• convert RSS format files to in-memory structures
• generally very strict at the library level wrt. core elements
• differences between RSS libs based on RDF or not
• (need specific list of tools)

Dedicated Parsers

• SAX, DOM, XSLT, XPath (generic XML libraries)
• Tools and applications that read RSS on their own
• Tools and eccentric drill bits applications built on top of generic libraries

It should be noted especially that there's a clear seperation of issues that affect applications (written to process known, specific RSS elements and modules) differently than generic libraries (which may or may not have specific RSS element and module information).

It would be very useful to have a set of basic examples within each of these usage categories and across several tool types. Something simple, along the lines of Ingo Macherius and Michel Rodriguez' "Ways to Rome" article that shows usage of different Perl modules to perform the same task.

Posted by: arthuryves at 08:46 AM | No Comments | Add Comment
Post contains 266 words, total size 2 kb.