Re: Comment on process

2005-01-08 Thread Roy T. Fielding
On Jan 8, 2005, at 2:03 PM, Danny Ayers wrote: No-one gains anything from overly protracted discussion. But I don't seen any extraordinary circumstances that might justify the imposition of cloture. Is there something related to the (still unexplained) deadline mentioned in Tim's recent post? Tim

PaceFeedRecursive

2005-01-09 Thread Roy T. Fielding
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, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/

Re: PaceFeedRecursive

2005-01-09 Thread Roy T. Fielding
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

2005-01-10 Thread Roy T. Fielding
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

2005-01-13 Thread Roy T. Fielding
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

Re: URI canonicalization

2005-01-31 Thread Roy T. Fielding
On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote: 5) Add a note saying something like Comparison functions provided by many URI classes/implementations make additional assumptions about equality that are not true for Identity Constructs. Atom processors therefore should use simple

Re: URI canonicalization

2005-01-31 Thread Roy T. Fielding
There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nobody cares because AT WORST the result is a bit of inefficient use

Re: URI canonicalization

2005-01-31 Thread Roy T. Fielding
On Jan 31, 2005, at 8:40 PM, Tim Bray wrote: Graham's right, the word identical is wrong, because in fact you will commonly encounter two instances of the same entry which aren't identical (e.g. the one in your cache and the one you just fetched). I suggest Software MUST treat any two entries

Re: URI canonicalization

2005-02-01 Thread Roy T. Fielding
On Feb 1, 2005, at 4:48 AM, Sam Ruby wrote: Roy T. Fielding wrote: There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers

Re: URI canonicalization

2005-02-01 Thread Roy T. Fielding
On Feb 1, 2005, at 7:46 AM, Tim Bray wrote: On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id http://tbray.org/uid/1000; as the same entry, even when I received

Re: URI canonicalization

2005-02-01 Thread Roy T. Fielding
On Feb 1, 2005, at 5:12 PM, Graham wrote: On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: There is no need to explain what different ids means -- any two URIs that are different identifiers will never compare as equivalent, regardless of the comparison algorithm used. Pardon? If I use case

Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder]

2005-02-05 Thread Roy T. Fielding
On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: What does that mean? SOAP is a Must Ignore format, but it also has a way of saying that you have to understand a particular extension; as I said before, this is one of the big problems with HTTP. mustUnderstand should be used sparingly, but

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-06 Thread Roy T. Fielding
. Aggregators are therefore required by Atom to only include the latest version of an entry within their own resource representations. I believe that these requirements reflect the desires of most of the participants in this working group, so it seems to me that the question has been answered. Cheers, Roy T

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Roy T. Fielding
On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote: Roy T. Fielding wrote: Aggregators do not consume feed resources -- they consume an iterative set of overlapping feed representations. This is only true of pull based aggregators that poll for feeds. None of the aggregators that I use are polling based

withdraw PaceFeedRecursive

2005-02-07 Thread Roy T. Fielding
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. Fieldinghttp://roy.gbiv.com/ Chief Scientist

Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder]

2005-02-07 Thread Roy T. Fielding
On Feb 6, 2005, at 6:50 PM, Mark Nottingham wrote: On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote: The problem with that statement (about HTTP) is that absence of a must-understand in HTTP is not one of its big problems. Yes, I know lots of people have talked about it as a limiting factor in

Re: BAG Question: What is a feed? Sliding-Window or Current-State?

2005-02-07 Thread Roy T. Fielding
developments that would cause the semantic web to reconsider its central assumptions. Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/

Re: Regarding Graphs

2005-01-09 Thread Roy T. Fielding
On Jan 9, 2005, at 4:23 AM, Danny Ayers wrote: There were a couple of points made in recent discussions that might have been misleading. One was that Atom is a tree. The XML may use that structure, and in it's simplest form the information being represented may be tree-shaped, but that isn't

Re: Madonna

2005-02-16 Thread Roy T. Fielding
On Feb 16, 2005, at 12:09 AM, Henry Story wrote: Now I would like to show how the Madonna example is relevant to Atom. In a mail recently Roy Fielding pointed to the following passage of the the RDF Semantics document: No, you pointed to that passage. I pointed to the RDF semantics intro.