On Feb 4, 2005, at 9:10 AM, Robert Sayre wrote:
My interest is in simplification, not abstraction. For example,
the draft wastes a lot of text talking in the abstract about
various constructs rather than simply defining one element for
each of those constructs.
Person, Date, and Text constructs al
Roy T. Fielding wrote:
Entry is a data model that easily fits the XML format, assuming
we ignore (for the moment) that entries and entry summaries are
actually quite different. It would be nice if atom would define
a distinct data model for entry first, before it got tied up in
the details of how
On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the
"Organization" Paces, including FeedRecursive, PaceEntriesElement,
PaceCollection. Here's why: they represent to increase the level of
abstraction in Atom, and in my experience, when the g
On Thursday, February 3, 2005, at 09:08 PM, Bob Wyman wrote:
I see two non-compelling benefits to PaceAggregationDocument over
PaceHeadInEntry:
1. In the case where a feed will contain more than one entry from a
"foreign" feed, you only have to include the atom:head data once. Thus,
there would
James Snell wrote:
On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
4. Massive changes need to be made to the specification when we
don't have a great deal of time left before we're supposed to be doing a
"Last Call." This is dangerous.
+1. Big +1.
I really regret w
On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
>
> Tim Bray wrote:
> > So I think I'm +1 on PaceAggregationDocument. (And I think
> > if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
> -1...
> PaceAggregationDocument does not seem t
+1 - someone else made a comment about OPML which really hit the spot;
if you try to make a format do all things, it does most of them
badly...
On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the
"Organization" Paces, including FeedRecursiv
Tim Bray wrote:
> So I think I'm +1 on PaceAggregationDocument. (And I think
> if we adopted that we could certainly lose PaceHeadInEntry, right Bob?)
-1...
PaceAggregationDocument does not seem to me to add much benefit for
all the costs that it entails. I'm particularly concern
On Feb 3, 2005, at 7:06 PM, Graham wrote:
On the other hand, the notion that sometimes you have collections of
feeds is easy to understand, easy to verbalize, and widely evidenced
in practice (cf PubSub & friends), if not perhaps widely seen outside
of geekland. So I think I'm +1 on PaceAggrega
Graham wrote:
On 4 Feb 2005, at 2:37 am, Tim Bray wrote:
On the other hand, the notion that sometimes you have collections of
feeds is easy to understand, easy to verbalize, and widely evidenced
in practice (cf PubSub & friends), if not perhaps widely seen outside
of geekland. So I think I'm +1
On 4 Feb 2005, at 2:37 am, Tim Bray wrote:
On the other hand, the notion that sometimes you have collections of
feeds is easy to understand, easy to verbalize, and widely evidenced
in practice (cf PubSub & friends), if not perhaps widely seen outside
of geekland. So I think I'm +1 on PaceAggreg
Tim Bray wrote:
On reflection, I am growing very negative on almost all of the
"Organization" Paces, including FeedRecursive, PaceEntriesElement,
PaceCollection. Here's why: they represent to increase the level of
abstraction in Atom, and in my experience, when the goal is
interoperability acr
12 matches
Mail list logo
