Les Orchard has conducted an experiment, comparing generating and parsing RSS-Data and XML/Schema/Namespace data within an RSS feed. Here are his conclusions:
- RSS-Data's convenience to script authors is at odds with the RSS 2.0 spirit of View Source.
- Producing and consuming RSS-Data could be easier than handling purpose-specific XML schema in scripts.
- Since RSS-Data doesn't follow in the spirit of XML specs and schema, using formal XML tools to handle this stuff will give you nothing but headaches. (Then again, it seems like some of the stuff that's fully in the spirit of XML yields headaches just the same.)
- RSS-Data might catch on and spread nonetheless, because lots of people don't read XML, don't use formal XML tools, and just write scripts to get their jobs done.
Interestingly, in all of the examples I've seen, they've focused mostly on reading and printing of the data, rather than processing and handling the data types themselves. As we look towards applications that consume and use the data in a typed fashion, just using XSLT or RegEx and print output isn't a clear enough example. For example, a comparison shopping client app that syndicated product data from multiple RSS-Data feeds would want to operate on numeric and date info. A well built RSS-Data deserializer would probably marshall data types into the most conveinient local form.
It's definately the case that a well-defined XML document entity for a custom format is easier to read than RSS-Data, which is intended primarily to be machine generated and read -- it's just a serialization format. I agree that this violates some of the principles of KISS, and also the view source mandate that lots of people require.
Nonetheless, I don't think this needs to be a binary decision --- it would be great to get a couple of RSS-Data libraries out there for Perl, Python, PHP, Java, CF, etc. and see what people come up with, and know from experience whether this is an approach that works.
12:32:30 PM 
|
|
