RE: [xml-dev] best practice for providing newsfeeds ?

["Joshua Allen" <joshuaa@microsoft.com>]

Title: RE: [xml-dev] best practice for providing newsfeeds ?

I am willing to be proven wrong, but I don’t see any evidence that any normal aggregator users are asking for a checkbox in their aggregator that distinguishes between “new” and “updated”.  Does anyone have feature requests they can use to back up the claim?  

 

Furthermore, I highly doubt that a user would care how this functionality was implemented, so long as it works.  I believe it’s a false assumption to say that additional feed metadata would be the only or the best way to implement this functionality.  In-document versioning is almost always a bad idea.  We agree that content producers will produce crappy feeds anyway, so in-document versioning is just one more thing for them to screw up.  Why would people push this, when there are other ways to accomplish the end-user demand (if such demand even exists)?

 

Sorry, but this totally sounds like the cart pulling the horse.

 

---

From: Dare Obasanjo
Sent: Tuesday, February 03, 2004 10:35 AM
To: Joshua Allen; bob@wyman.us; 'Michael Champion'; 'XML DEV'
Subject: RE: [xml-dev] best practice for providing newsfeeds ?

 

Again I disagree. Content producers don't care how crappy the feeds they generate are as long as their HTML page is fine. It is content consumers (i.e. users of news aggregators) that clamor for this functionality. This is the duality of the syndication debate which much to my chagrin is always balanced towards what is easiest for content producers to do as opposed to what provides most value to content consumers.

 

--

PITHY WORDS OF WISDOM

Blessed are the meek for they shall inherit the Earth, minus 40% inheritance tax.

 

---

From: Joshua Allen
Sent: Tue 2/3/2004 10:31 AM
To: Dare Obasanjo; bob@wyman.us; 'Michael Champion'; 'XML DEV'
Subject: RE: [xml-dev] best practice for providing newsfeeds ?

By people I meant tools.  I get a few hundred posts a day that show up as “new” when they are old, simply because people have crummy tools that reset the pubDate on *all* posts to be whatever date the feed gets updated.  I also am pretty sure that these people have no idea that their tools are doing this, and don’t lose any sleep over it.  In other words, normal people don’t care about what date gets inserted, and only the techies argue about it.  I don’t believe that the call for multiple date fields is being driven by significant end-user demand.  I think that’s total bull.

 

---

From: Dare Obasanjo
Sent: Tuesday, February 03, 2004 9:13 AM
To: Joshua Allen; bob@wyman.us; 'Michael Champion'; 'XML DEV'
Subject: RE: [xml-dev] best practice for providing newsfeeds ?

 

I disagree. Most tools insert this date automatically. I'd be very suspicious of a tool that allowed users to directly edit the posting date of an entry, let alone edit the original + posting date. I agree with Bob that having a published + updated date would be useful.

 

--

PITHY WORDS OF WISDOM

Blessed are the meek for they shall inherit the Earth, minus 40% inheritance tax.

 

---

From: Joshua Allen
Sent: Tue 2/3/2004 9:02 AM
To: bob@wyman.us; Dare Obasanjo; 'Michael Champion'; 'XML DEV'
Subject: RE: [xml-dev] best practice for providing newsfeeds ?

> date that it was last modified. So, users get entries that appear  to
> be "old" even when they are "new." This confuses them. The issue here
> has *nothing* to do with data format -- it is a question of semantics,

My experience shows exactly the opposite; people report "new" when actually a post is old.  But in any case, I fail to see how adding another field will stop people from putting the wrong dates in those fields -- the semantics of "pubDate" are remarkably clear, and people still screw it up.  I would bet that in 99% of cases, people screw it up because they don't know better, NOT because "pubDate is the only field available and I really, really, want to store the last-update date in the field". 

Solving user ignorance by adding more features is not very smart.