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
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/
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
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,
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
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
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
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
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
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
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
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
. 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
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
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
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
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/
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
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.
19 matches
Mail list logo