Subject: Re: PaceIntrospection: Is another file format really needed?

From: [email-masked]
Date: 1 Jul 2004 13:08:09 -0000

--- [email-masked] wrote:
> >A feed of search results, does not fit
this limiting definition
> >of <feed>.
> >
> How so? I'm subscribed to
"Robert Sayre" on pubsub. Seems like a stream 
> to me. Or did you mean typing
a term in and getting a search results 
> back? I would probably use an HTML
page for that.

At Feedster you can also subscribe to search results
for a specific term. You can either sort the results by date or by relevance.
The first type of search fits your definition of <feed>, the second does not.

compare:

http://feedster.com/rss.php?q=duck&sort=&type=echo&ie=UTF-8&limit=15

and:

http://feedster.com/rss.php?q=duck&sort=&type=echo&ie=UTF-8&limit=15&sort=relevance

Another example of another "non-conforming" feed:

http://www.daypop.com/blogrank/rss.xml

The items in this <feed> are ordered according to ranking and hence this
feed does not represent a frame of pushed stack.

> Let's turn back to the
more interesting questions:
> What problem is solved by making feed the root
element for both purposes? 

It avoids introduction of a new <introspection>
format for representing information, which can be represented just as well
by <feed>, without the need for shoe-horning, if the definition of <feed>
 is not limited.

It avoids the need for constant reinventing of a new format,
whenever you come across something, which does not fit the notion of "frame"
of a pushed stack. 
F.e. I want to be able to have a list of the templates
used by my Blogging account. I'd use <feed> for that too. What would you use?

> Why does it matter?

Nothing really matters, but I'd say: simplicity,
elegance, innovation friendly.

Could you also please answers the same two
questions, for the opposite case where a seperate <introspection> format is
necessary?

Peter

---

From: Robert Sayre <[email-masked]>
Date: Thu, 01 Jul 2004 09:39:42 -0400

>feed does not represent a frame of pushed stack.

Both of these fit just fine. The only difference is that they might show 
you entirely new content each time. My aggregator would probably build 
up a history of it anyway.

>format for representing information...
>
>It avoids the need for constant reinventing of a new format...
>

Could I subscribe to your templates? That would be useful :/
It seems you want <feed> to replace all XML elements that contain child 
sequences. I think that's of dubious utility.

Feeds are not collections in the general sense. They are resources you 
"subscribe" to in order to receive batched push updates.

>questions, for the opposite case where a seperate <introspection> format is

No, I can't. When we're done specifying the introspection capabilities 
we're going to support, we'll take a look at folding it back into the 
feed format. There's no reason to try and deal with them as one format 
right now-- the only  reason you gave was "avoid another format".

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Thu, 1 Jul 2004 08:08:57 -0600

> "subscribe" to in order to receive batched push updates.

It looks like we could save ourselves a considerable amount of 
discussion if we were to nail down a conceptual model of what a feed 
is, what an entry is (what a person is), etc.  If you do a title search 
on the wiki for "Model", a number of pages come up.  Does anyone whose 
been around longer than I have know whether any of these have been 
"officially" adopted?  If so, let's refer to them, and when questions 
arise that aren't answered by them, augment them so that we can move 
forward.

I for one do see feeds as being more generalized collections.  Or at 
least as being usable as generalized collections, though their primary 
use is as reverse sequential lists of ... some sort of data.  A pencil 
is usually used for writing, but I don't have a problem with people 
using them as defensive weapons or decorations or whatever else they 
might work just fine for.  If it can do the job without making people 
jump through hoops, then a "better" solution isn't needed.  And if it 
saves jumping though hoops, then maybe it is the best solution.

> right now.

If we need to specify capabilities first, then arguments against 
reusing the feed format are no more productive than arguments in favor 
of doing so.  So what capabilities do we need?  To find the endpoints 
for things like posting and editing, to discover which capabilities a 
server supports.  Anything else?

---

From: Robert Sayre <[email-masked]>
Date: Thu, 01 Jul 2004 10:28:51 -0400

Antone Roundy wrote:

> of doing so.

Yes, they so are. We have unagreed upon requirements that may or may not 
be a good fit for <feed>.

http://c2.com/cgi/wiki?PrematureGeneralization

Robert Sayre