JD on EP

The meta-issue here is "Why are these simple points apparently so difficult to understand?" Robert's characterization of my prior paragraph as "He says it's a waste of bandwidth" brings this concern even more to the fore -- the meta-issue here is the frequency of mischaracterizing arguments, and the insistence that all XML offerings must be full-content. Such repeated misunderstanding is difficult for me to explain, which is why a hidden agenda should remain within the set of viable hypotheses.

For the RSS angle itself, this part of the discussion can be boiled down into three very simple points:

1. It remains useful to efficiently know when a website has changed. (From the early days of Apple's HotSauce, Netscape's RDF, and Microsoft's own CDF up through today, I have not seen this set of needs made obsolete. With occasional-connectivity, pocket-devices, customized content aggregation, and particularly with widely-embedded processors (heck, even including Microsoft's SPOTwatch!) it remains useful to efficiently pull a notification of changed content from multiple sources. I do not recall Robert acknowledging this point... seems to be off-the-radar.)

2. Full-text XML can indeed often complement the richer HTML presentation of a website. (This is similar to Robert's main point about how nice an unstyled relatively compact presentation can be, but he tends to use "eliminate HTML" rather than "complement HTML" as his main rejoinder to other observations. Sites and readers differ, and I prefer to see increasing choice rather than one single path, myself.)

3. Full-text XML, while useful, is not useful or flexible enough to push XML-formatted compact site notifications out of existence, which it threatens to do with this "all RSS should be fulltext" argument. (This is particularly worrisome if Microsoft does to RSS what it did to document browsers (integrating system-level native-code instead of the existing application-level extensions, with identity-authentication as a security mechanism rather than actual sandboxing) and which it did to email readers (adding styling, scripting, pictures, bad quoting styles, system-level integration). We know what happened to DHTML and email. I can't assess the motives of others, but this pattern of mishearing what others say is the worrying part for me.)

In retrospect, we might not have this problem today if the early terms of meta-content format, resource-description format, channel-definition format and so on up to Rich Site Summary had not also been also given the cute yet confusing parallel label "Really Simple Syndication"... things would have been clearer without that one particular distortion, but that's water under the bridge now.

What we *can* do is to make sure that compact notifications of resource changes are not squeezed out of existence by people who now complain "hey those web pages are too bloated" or "hey my email is unsafe and too bloated" or "hey my browser doesn't have bookmarked tab groups" or "hey the serverside syndicators I use are too bloated" or "hey the writers I read never efficiently and accurately get to the point".

It would be great if there were a standard way to retrieve just the full-text with minimal structural tags and with no display tags, agreed.

But that need doesn't justify squeezing out the efficient notification of website changes which is currently called "RSS".

Make a new format. Be happy. Everyone will cheer you on if you increase choice rather than reduce choice.

But please don't misstate what I try to clearly explain on the way to doing something else, because then I have to try to evaluate what's really going on, and what I should rationally do next...!