Here is another wild (or not?) thought.
Not so wild to me.
All this discussion comes down to the requirement of generating some XML out of the content usually served by the reader, if that's possible (and it is possible for some of the types of the content), in order to feed this XMLized content into the view. This generated XML is somewhat "equivalent" to the binary represenation for the purpose of view building. So, I'm going to the conclusion that some types of readers can be paired with the generator producing "equivalent", but XMLized, content. The best place to indicate such pairing is the time when you declare a reader:
<snip idea="interesting"/>
The syntax looks a bit ugly to me, but the idea seems much more sane to me.
PS: Modifying sitemap syntax to allow reader/generator pairs with some "unless" attrbiutes looks awful to me.
Complete agreement. One of the reasons for the sitemap (*the* reason?) is for the simple and easy management of a site. Some recent proposals seem to be pushing in the direction of Apache HTTPd's mod_rewrite; A lot of flexibility by adding "just one more construct."
From the mod_rewrite page:
"The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail."
-- Brian Behlendorf Apache Group
"Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo."
-- Brian Moore [EMAIL PROTECTED]
It'd be a shame if the sitemap became a cousin to mod_rewrite despite the cool voodoo.
- Miles Elam
P.S. I shudder to think of what will happen to search index creation times when multi-megabyte Word documents and the like are sent down the pipe. The parsers, however efficient they may turn out to be, will still have to contend with seemingly endless streams of seemingly pointless formatting cruft. I'm sure we've all seen 10MB files that would be <100K in proper HTML I'm sure. Ah well...'tis the cost of progress, I guess.
