Re: PaceFeedRecursive

> PaceFeedRecursive -1

withdraw PaceFeedRecursive

Please withdraw PaceFeedRecursive because forcing everything to be an entry is sufficient justification to forbid inclusion by anything other than reference. The other (still needed) bits are in PaceHeadless. Cheers, Roy T. Fielding<http://roy.gbiv.com/> Chief Sci

Re: PaceFeedRecursive

On 19 Jan 2005, at 10:38, Henry Story wrote: I think the easiest way to get what you want is a 2 step procedure: 1. Merge the Head with the Entry constructs. They are not different enough for the difference to be important. 2. Make a Feed a subclass of Entry, with the extra property of be

PaceFeedRecursive

-1: recursion is too complex and bulky. But we could (should?) specify lack of recursion in terms of particular types of Atom Documents or particular profiles, leaving the door open for extensions to define document types that allow recursion.

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: I suspect that once people see some examples, objections will surface. I've included an example of each approach, so people can compare the two methods. I have not positioned them as spec text. The spec requires more examples no matter which approach the WG chooses. Good examp

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I gather that a format-05 compatible feed, thus: I suspect that once people

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I suspect that once people see some examples, objections will surface. It'

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. It would be much easier to discuss the pace with an example. I gather that a format-05 compatible feed, thus: ... would become s

Re: PaceFeedRecursive is filled in

Robert Sayre wrote: Hmm. How do I do a linkblog with this restriction? I believe a linkblog should always have atom:content which provides some information on the reason why you posted the link or a comment on the link or something similar. -- Anne van Kesteren

Re: PaceFeedRecursive is filled in

Sam Ruby wrote: Robert, can you take a stab at updating section 1.2 for this Pace? Yes, but the Pace is complete without it. I'll also note that this example is not valid. It does not contain either a summary or content element. Hmm. How do I do a linkblog with this restriction? Robert Sayre

Re: PaceFeedRecursive is filled in

Robert, can you take a stab at updating section 1.2 for this Pace? I'll also note that this example is not valid. It does not contain either a summary or content element. One thing to consider is to do like what was done in Atom 0.3 [1]: provide both a minimal and maximal example. - Sam Ruby [

PaceFeedRecursive is filled in

Sam Ruby wrote: I'm recommending AtomAsRDF and PaceFeedRecursive for closure merely because they are incomplete. If they become complete, I will update their status accordingly. Please do. Roy T. Fielding wrote: Unfortunately, I have a paper deadline on Tuesday and can't procras

Re: PaceFeedRecursive

other paces regarding aggregators and digital signatures. http://www.intertwingly.net/wiki/pie/PaceFeedRecursive Unfortunately, I have a paper deadline on Tuesday and can't procrastinate any longer, so someone else can finish the details or I'll finish it later in the week. Cheers,

Re: PaceFeedRecursive

--On Thursday, January 13, 2005 06:55:53 PM -0500 Sam Ruby <[EMAIL PROTECTED]> wrote: The proposal apparently is for feeds to contain other feeds by containment. My question is whether it would make sense to also support feeds containing other feeds by reference, perhaps via a link element or via a

Re: PaceFeedRecursive

On Jan 13, 2005, at 3:55 PM, Sam Ruby wrote: I realize that the proposal isn't flushed out, but a question nevertheless. The proposal apparently is for feeds to contain other feeds by containment. My question is whether it would make sense to also support feeds containing other feeds by refere

Re: PaceFeedRecursive

/PaceFeedRecursive Unfortunately, I have a paper deadline on Tuesday and can't procrastinate any longer, so someone else can finish the details or I'll finish it later in the week. I realize that the proposal isn't flushed out, but a question nevertheless. The proposal apparently is for feeds t

Re: PaceFeedRecursive

On 11/1/05 6:59 AM, "Danny Ayers" <[EMAIL PROTECTED]> wrote: > Ok, I don't think there is any benefit in the normal case (feed ::= > meta, (meta, content)*), but the recursive nesting method makes it > possible to convey information about relationships between feeds. > Which begs the questions: >

Re: PaceFeedRecursive

On Jan 10, 2005, at 6:54 AM, Graham wrote: Seriously, though, all you've done is not bothered to flatten the data at any point. Why is that a goal? We know all of the data is in the leaves, so "flattening" them is what happens when the entries are processed depth-first. While this may please you,

Re: PaceFeedRecursive

Danny Ayers wrote: On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote: 6. Concern that "Feed of Feeds" really doesn't buy you much that Head In Entry doesn't already provide in the normal case. Ok, I don't think there is any benefit in the normal case (feed ::=

Re: PaceFeedRecursive

On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote: > > Roy T. Fielding wrote: > > a proposal on making the feed element recursive > The primary arguments against "Feed of Feeds" have been (my > apologies if I forgot some...) Thanks Bob. IMHO there are pretty stro

Re: PaceFeedRecursive

Bob Wyman wrote: Roy T. Fielding wrote: a proposal on making the feed element recursive (Speaking for myself, I'm not clued-up enough to understand the problem / use-case Roy's pace solves) Equivalent proposals have often been made in the past (sometimes by me!). These proposals fall in t

Re: PaceFeedRecursive

://www.intertwingly.net/wiki/pie/PaceFeedRecursive Perhaps instead of making feed recursive, it would be better to have one more kind of document element to be used for aggregate feeds. For example

RE: PaceFeedRecursive

Roy T. Fielding wrote: > a proposal on making the feed element recursive Equivalent proposals have often been made in the past (sometimes by me!). These proposals fall in the category that we've come to know as "Feed of Feeds". Each time the proposal has been made, it has been rejected. Th

Re: PaceFeedRecursive

On 10 Jan 2005, at 4:10 am, Roy T. Fielding wrote: On Jan 9, 2005, at 5:38 PM, Graham wrote: -1; Conceptual masturbation. Wow, you like it that much? It must be a really good idea, then, since we are all just doing this to keep you stimulated. Sarcasm and everything. Wow. Seriously, though, all yo

Re: PaceFeedRecursive

On Sun, 9 Jan 2005 16:36:04 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote: >http://www.intertwingly.net/wiki/pie/PaceFeedRecursive I like it, but seem to remember a similar proposal being rejected - anyone..? This approach should be pretty straightforward to program against, a

Re: PaceFeedRecursive

On Jan 9, 2005, at 5:38 PM, Graham wrote: -1; Conceptual masturbation. Wow, you like it that much? It must be a really good idea, then, since we are all just doing this to keep you stimulated. Roy

Re: PaceFeedRecursive

-1; Conceptual masturbation. Graham smime.p7s Description: S/MIME cryptographic signature

PaceFeedRecursive

I just created a starting point for a proposal on making the feed element recursive, eliminating the need for RDF syntax, atom:head, and a bunch of things proposed in other paces regarding aggregators and digital signatures. http://www.intertwingly.net/wiki/pie/PaceFeedRecursive Unfortunately, I