Hi everyone,

  Well I am having this delma..RSS/ROR. I am not exactly the most
  informed technical person there is... I just know enough to get myself
  in trouble... I want an RSS feed for my website. But I have 2500
  items... every program that I have found wants you to enter everything
  manually... I found a program that crawls your site and produces a RSS
  Sitemap... But is that the samething as an RSS Feed? Not only do I
  want this for the search engines... but also for Froogle. They have a
  program but, but its for individual products.. and they only last 30
  days... needless to say it would take me 30 days to even get it all
  up.  Not only that, but. I do not have access to the database. Would
there be a program that would crawl the website and then produce a
feed? If someone could help me, that would be wonderful.

  Thanks
  Pink Kitty

Where I can read technical documentation about RSS ?

Maybe this question is outside the scope of this list...

but I was wondering if anyone knew of a non-server based blogger.com to RSS
converter...

thanks for any pointers...

Fred Edwards

> GUID is a unique indentifier? except that it's not a global address,
> it something useful inside a local system.

Well, do a little more research on it.  You'll find otherwise.

> we have these already in terms of these funny URI/URL thingy's

Which require significantly greater amount of CPU processing as they're strings.
GUIDs can be represented as string but as hex numbers and can be manipulated as
such.

> GUID's are badly over used by developers, they are not user friendly,
> they provide no useful information and they are horrible to type...

So don't type them.  This isn't something a user is ever going to manually
create.

> how many websites have you seen where developers create article id's
> using GUID's

Several actually.  As I'm the lead editor behind Syndic8.com I've had /quite/ a
bit of access and familiarity with over 15 thousand different feeds generating
over 110,000 headlines *per day*.  So I know what I'm talking about.

> please keep rss simple, this guid's idea sounds like the disaster
> that happened when people mixed RDF into RSS...

Ah well, then it's rather pointless to discuss it with you then, isn't it?

-Bill Kearney

Contrary to popular mythology, an OSF standard GUID can well be
utterly unique.

The value behind using a GUID is not in readability, it's in
programmatic accessibility.  Why bother forcing the use of horribly
inefficient string processing on a URI when tools against the hex
bytes are orders of magnitude faster?

They're not expected to *EVER* be typed nor viewed by human beings.
Just something that let's the machinery do it's thing.

As for disasters, frameworks have value, regardless of what the
overly simplistic folks would have you believe.

-Bill Kearney

> GUID is a unique indentifier? except that it's not a global
address,
> it something useful inside a local system.
>
> we have these already in terms of these funny URI/URL thingy's
>
> GUID's are badly over used by developers, they are not user
friendly,
> they provide no useful information and they are horrible to type...
>
> how many websites have you seen where developers create article
id's
> using GUID's
>
> please keep rss simple, this guid's idea sounds like the disaster
> that happened when people mixed RDF into RSS...

GUID is a unique indentifier? except that it's not a global address,
it something useful inside a local system.

we have these already in terms of these funny URI/URL thingy's

GUID's are badly over used by developers, they are not user friendly,
they provide no useful information and they are horrible to type...

how many websites have you seen where developers create article id's
using GUID's

please keep rss simple, this guid's idea sounds like the disaster
that happened when people mixed RDF into RSS...

> I think this is a good idea, as long as the "more complete" XML is
> still of the RSS/RDF variety. That is, the compact version would be
> of the .9x variety, and the complete version would be of the 1.0
> variety (with modules etc). This could apply to individual items of
> a feed, or the entire feed itself.

I don't know about this suggestion in that you're proposing the mix
of 0.9x and 1.0 formats.  While an environment may understand both is
it reasonable to expect them to switch on the fly?

I'd be more inclined to suggest the "more complete" document use ONLY
RSS-1.0 style format.  Or better yet, RSS-2.0 (being 0.9x with
namespaces and RDF as optional)

> This should be cause for a new GUID. You mentioned in another place
> (forget where exactly) the idea of a "path." I looked into the
> pointers you provided and agree that it's a good idea. If I modify
> an item I have consumed and then redistribute it (with
> modification) it should be given a new GUID, and have another
> element added to the path. (perhaps the path ought be the string of
> GUIDs, new to old)

I'm ok with the idea of attaching a new GUID when an environment re-
routes the item; even without additional modification.  The re-
routing of an item into a fresh space is itself often a significant
bit of metadata.  I'd suggest, however, the Path of previous
identifiers not be concatenated into a string.  I'd prefer an list of
some sort.  Do existing XML environments support ordered arrays?  Or
would we be better served attaching an array of structs to allow for
attaching the server URL, item URL, etc... ?

-Bill Kearney

> One, allow a program that possess a GUID for an *item* to be able
> to
> return to the item's source and request a "more complete" XML
> represenation of the item.  This would let programs using the RSS
> find out more about an item.  This would let the feed remain
> reasonably compact.  It'd also allow a site to deliver
> considerably
> more complete data, but only when requested.  This could save a
> fair
> amount of CPU as many items probably won't ever get requested.

I think this is a good idea, as long as the "more complete" XML is
still of the RSS/RDF variety. That is, the compact version would be
of the .9x variety, and the complete version would be of the 1.0
variety (with modules etc). This could apply to individual items of
a feed, or the entire feed itself.

> Two, allow a client program to 'carry along' some source
> information
> as an item moves through site to site.  Many item do have a source
> and are simple echoed from one feed to another.  Yes, some feeds
> do
> add more information on top of an item.

This should be cause for a new GUID. You mentioned in another place
(forget where exactly) the idea of a "path." I looked into the
pointers you provided and agree that it's a good idea. If I modify
an item I have consumed and then redistribute it (with modification)
it should be given a new GUID, and have another element added to the
path. (perhaps the path ought be the string of GUIDs, new to old)

Hi all,

What's the point of using a GUID?  What situation is going to require
having one?

I've suggested in the past that there needs to be a way for a program
to uniquely identify an item.  Note that I'm saying this is a means
for a program to do the identifying, not a person.  As such this
hypothetical program would presumably be doing something FOR a person.

I'd like to see two reasons to use a GUID be taken into consideration.

One, allow a program that possess a GUID for an *item* to be able to
return to the item's source and request a "more complete" XML
represenation of the item.  This would let programs using the RSS
find out more about an item.  This would let the feed remain
reasonably compact.  It'd also allow a site to deliver considerably
more complete data, but only when requested.  This could save a fair
amount of CPU as many items probably won't ever get requested.

Two, allow a client program to 'carry along' some source information
as an item moves through site to site.  Many item do have a source
and are simple echoed from one feed to another.  Yes, some feeds do
add more information on top of an item.  Yes, this could lead to
debates over what sort of provenance is suitable for attaching to an
item.  Again, this'd be a great reason for an XML interface to remain
available for an item (via it's GUID).

This leads into several other areas for DOI and DRM.  Both digital
object identifiers and digital rights management are of great
interest to many content providers.  Sure, a lot of stuff is free and
doesn't really care about these concepts.  However, that's no reason
not to have a discussion of the concepts or to allow the spec to
optionally accomodate them.

And as to "stop energy", this list was resurrected from the dead as a
counter to it.  Let's all try to keep things moving forward this time.

-Bill Kearney

It would appear there's interest brewing in evolving new features for
RSS.

I have an archived copy of the old messages from a previous instance
of this group.  I'll see about bringing them back online.

-Bill Kearney

> BTW: I couldn't follow the link to Simon Fell's use-case and
> discussion on the pubDate and expirationDate. Yahoo tells me
> there's no message #15.

The archives were deleted some time ago.  Yahoo had some sort of accident and
many groups were lost.  They never reloaded this one's archives.

-Bill Kearney

On tuesday, april 30, 2002, at 02:19 , tsaiello wrote:
> It seems to me that in RSS 0.93 there are a couple optional dates.
> Namely pubDate and expirationDate.  However, I'm not sure exactly
> what the definition really means at it is a bit misleading to me.
> From RSS 0.93:
>
> <pubDate> is an optional sub-element of <item>.

Ah, how could I miss that!? :-)

> Its value is a date, indicating when the item will become available.
>
> Perhaps one could take this to mean a date when the item will (or
> has) become available.

I certainly would use that date when displaying weblog entries.

Another, somewhat related question: why represent time using the
long deprecated RFC822 date format?

BTW: I couldn't follow the link to Simon Fell's use-case and
discussion on the pubDate and expirationDate. Yahoo tells me
there's no message #15.

Cheerio,
Malte

It seems to me that in RSS 0.93 there are a couple optional dates.
Namely pubDate and expirationDate.  However, I'm not sure exactly
what the definition really means at it is a bit misleading to me.
From RSS 0.93:

<pubDate> is an optional sub-element of <item>.

Its value is a date, indicating when the item will become available.

Perhaps one could take this to mean a date when the item will (or
has) become available.

Tim

--- In reallySimpleSyndication@y..., Malte Tancred <malte@o...> wrote:
> Hello!
>
> A few of my collegues and I have set up some weblogs at our
company.
> We've used a simplistic perl script called blosxom, which can be
found
> here:
>
>    http://www.oreillynet.com/~rael/lang/perl/blosxom/
>
> We got the idea to automatically merge our blogs at a separate URL.
The
> HTML and RSS generated from this site would contain, say the ten
latest
> entries of all the blogs.
>
> After looking at the specs my interpretation is that there
currently is
> no way of timestamping an RSS <item>. Am I right in this assumption?
>
> If my assumption is correct I propose that a time stamp be added to
each
> <item> of a <channel> so that clients reading an RSS file may get
the
> information right.
>
> If I'm totally off track here I beg you to forgive my ignorance.
>
> Thank you for your time.
>
> Cheerio,
> Malte
>
> --
> Malte Tancred
> Computer programmer, Oops AB, Sweden
> mailto:malte@o...
> http://www.oops.se/

Hello!

A few of my collegues and I have set up some weblogs at our company.
We've used a simplistic perl script called blosxom, which can be found
here:

    http://www.oreillynet.com/~rael/lang/perl/blosxom/

We got the idea to automatically merge our blogs at a separate URL. The
HTML and RSS generated from this site would contain, say the ten latest
entries of all the blogs.

After looking at the specs my interpretation is that there currently is
no way of timestamping an RSS <item>. Am I right in this assumption?

If my assumption is correct I propose that a time stamp be added to each
<item> of a <channel> so that clients reading an RSS file may get the
information right.

If I'm totally off track here I beg you to forgive my ignorance.

Thank you for your time.

Cheerio,
Malte

--
Malte Tancred
Computer programmer, Oops AB, Sweden
mailto:malte@...
http://www.oops.se/