RSS 2.0 namespace versus RSS-Data, Part 2: First impressions
Okay, I got the example data out there. Here's what's first on my mind about it:
Man, that RSS-Data is one verbose piece of XML. The Amazon-specific namespace version looks much more compact and readable; I'd rather View Source on that one.
Python comes out of the box with xmlrpclib, and other languages have XML-RPC facilities available as well. I can't imagine it'd be too hard to get a hold of the core of it and employ it in unmarshalling the RSS-Data straight into idiomatic Python structures. On the other hand, I'll need to write my own handlers for the Amazon XML using the XML parser modules that come with Python.
With its clean, almost self-documenting structure, the Amazon XML is easily handled with XPath and XSL. If I had a pile of ProductInfo elements in a document, I could yank out all their images with something like:
Using the RSS-Data example, it'd probably be something more like:
//sdl:data/sdl:struct/sdl:member/sdl:name[@text='ImageUrlSmall']/../sdl:value, and that's not considering if I have mixed kinds of RSS-Data schema represented in the feed.
I suppose I could help this out by surrounding the struct with another struct, containing one member named 'AzProductInfo', making the path something like so:
And these are the conclusions I'm jumping to at the moment, before experimenting:
- 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.