[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
> unless you are suggesting that an items ID should be changed
> every time it is updated which has its own set of problems.
Dave Winer's suggestion that GUID be used to disambiguate
versions of items does, in fact, require that a unique GUID be
assigned to every new version or variant of an item. This is, of
course, one of the big reasons why his proposal has not been widely
implemented.
There a quite a number of other problems with GUID... Some
include:
A GUID can be either a pure identifier or it can be a
"permaLink" which is effectively an URL. If you wish to have both a
unique identifier which is immutable as well as a consistent location
to find the "latest" version of some item, which could change, it
isn't obvious how you accomplish this with the RSS V2.0 guid element.
It isn't for instance, clear from the specification whether you can
have multiple guids for a single item.
Also, GUID is defined as a "unique" identifier for an item.
However, since it can also be a "permaLink" URL, one must wonder what
it is an identifier for... Often, when people update an entry in their
blogs, they have the updated entry use the permaLink of the original
entry. (There are many reasons why this is reasonable and good.) This
means that such a permaLink is NOT a unique identifier if we believe
that various versions or variants of items can be distinguished via
their GUIDs. A "permaLink" can refer to multiple versions of a single
item. It isn't therefore, a "unique" identifier for an item.
As is the case with much of the RSS V2.0 spec, there was the
seed of a good idea here but the spec is terribly written, ambiguous,
incomplete, etc. When even the author of the spec can suggest in a
public forum that an RSS GUID can be used as a unique identifier to
disambiguate versions, that just shows you how little understood and
confusing this specification is. GUIDs in RSS are *not* unique. If
Dave Winer can't understand his own spec, why should the rest of us
even try to?
bob wyman
-----Original Message-----
From: Dare Obasanjo [mailto:dareo@microsoft.com]
Sent: Tuesday, February 03, 2004 3:27 PM
To: Dave Winer; bob@wyman.us; Joshua Allen; Michael Champion; XML DEV
Subject: RE: [xml-dev] best practice for providing newsfeeds ?
Uniquely identifying items and telling if an item is changed are
orthogonal problems. I fail to see why you think they are related
unless you are suggesting that an items ID should be changed every
time it is updated which has its own set of problems.
--
PITHY WORDS OF WISDOM
A day off is usually followed by an off day.
This posting is provided "AS IS" with no warranties, and confers no
rights.
-----Original Message-----
From: Dave Winer [mailto:dwiner@cyber.law.harvard.edu]
Sent: Tuesday, February 03, 2004 11:39 AM
To: Dare Obasanjo; bob@wyman.us; Joshua Allen; Michael Champion; XML
DEV
Subject: Re: [xml-dev] best practice for providing newsfeeds ?
I've been lurking on this thread for too long.
RSS 2.0 has an element which is designed to neatly solve the problem
that Bob Wyman is saying RSS 2.0 doesn't have a solution for.
http://blogs.law.harvard.edu/tech/permalinksNewsAggregators
One bit of advice to you all: RTFM.
Dave
----- Original Message -----
From: "Dare Obasanjo" <dareo@microsoft.com>
To: <bob@wyman.us>; "Joshua Allen" <joshuaa@microsoft.com>; "Michael
Champion" <mc@xegesis.org>; "XML DEV" <xml-dev@lists.xml.org>
Sent: Tuesday, February 03, 2004 12:12 PM
Subject: RE: [xml-dev] best practice for providing newsfeeds ?
> Perhaps I have trouble understanding your point because you aren't
illustrating it clearly. You claim that people complain because posts
with dates like "August-2003" appear as new. Considering that that was
about 6 months ago I concluded that either you have buggy code or like
my toy RSS aggregator when you see dates in weird formats like
"August-2003" you fail to parse them and use the current date.
>
> Having a publication date and a last updated date would be goodness.
It is
annoying that the various flavors of RSS have only one date field for
items and it is optional. On the other hand, I think having 3 dates as
ATOM does is bordering on the ridiculous.
>
> --
> PITHY WORDS OF WISDOM
> Blessed are the meek for they shall inherit the Earth, minus 40%
inheritance tax.
>
> ________________________________
>
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Tue 2/3/2004 8:48 AM
> To: Dare Obasanjo; Joshua Allen; 'Michael Champion'; 'XML DEV'
> Subject: RE: [xml-dev] best practice for providing newsfeeds ?
>
>
>
> Dare Obasanjo wrote:
> >It seems you are complaining about people using invalid date
formats
> No. Your comment is a complete distortion of what I wrote. The
> issue is that RSS only provides for one date (pubDate) which is
> typically used to indicate an item's "creation date". When an item
is
> updated, it is typically published with its "creation date" -- not
the
> 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,
> not syntax.
> I find it somewhat telling that the author of one of the better
> RSS aggregators would have trouble understanding this point. This is
> clearly an illustration of the problems and confusions that can
result
> from a format as poorly specified as RSS.
>
> > The main problem with dates in the major RSS specs
> > is that they are optional.
> Optionality is an issue which is completely orthogonal to
the
> understanding of those dates that *are* present. If the meaning of a
> date is ambiguous, it doesn't much matter if it is present or not.
>
> bob wyman
>
> -----Original Message-----
> From: Dare Obasanjo [mailto:dareo@microsoft.com]
> Sent: Tuesday, February 03, 2004 2:28 AM
> To: bob@wyman.us; Joshua Allen; Michael Champion; XML DEV
> Subject: RE: [xml-dev] best practice for providing newsfeeds ?
>
>
> The main problem with dates in the major RSS specs is that they are
> optional. It seems you are complaining about people using invalid
> date formats which have nothing to do with the specs given that both
> major flavors of RSS have well-defined descriptions of what valid
> dates look like.
>
> --
> PITHY WORDS OF WISDOM
> Blessed are the meek for they shall inherit the Earth, minus 40%
> inheritance tax.
>
>
>
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Mon 2/2/2004 2:24 PM
> To: Joshua Allen; 'Michael Champion'; 'XML DEV'
> Subject: RE: [xml-dev] best practice for providing newsfeeds ?
>
>
> Joshua Allen wrote:
> >> original creation. (Atom defines both "created" date and "issued"
> >> date. This allows the distinction to be made.)
> > Great, a techie feature. My grandmother certainly didn't ask for
> that one.
> Well, other people's grandmothers *did*. Every day I get
mail
> from someone asking: "Why are you telling me that this entry which
is
> dated "August-2003" is "New"? How stupid is your code that it can't
> read a date!"
> The lack of metadata in RSS confuses users more than it
> confuses us.
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
