On 3/2/05 7:18 PM, Robert Sayre [EMAIL PROTECTED] wrote:
This is better. I guess I just hadn't grok'd the idea of using
entries to reference feeds, but now that I see the angle brackets I
get it.
Yes, feeds are entries.
no, feeds are collections, entries describe resources, and while
James Snell wrote:
In any case, we're talking about something as simple as the name of a
single element. I just don't see any real technical value in changing
it's name. It doesn't make processing any easier. It doesn't change
any of the functional semantics. It doesn't address any critical
Robert Sayre wrote:
1. XML containment relates feed and entry metadata to the data being
described, thereby defining a consistent model for future extension
elements;
I'm dubious about this claim. XML containment has even less semantic
grist to it than UML aggregation. My sense is when we get
On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
James Snell wrote:
I'm just thinking ahead a bit on this, but I am wondering if it would
be possible for those of us interested in proposing non-core
extensions to Atom to use the Wiki as the forum for sharing proposals
Bill de hÓra wrote:
If,
- 6.2 was dropped and probably
- the first sentence of the Pace was dropped,
- the rest of the 1st para was dropped down into 6.1
- there was some weasel wording about RFC3023 compliance
how would you feel about the rest of it?
...
I think the main issue here is first
This doesn't seem to have made it when I sent it last night, so here it
is again:
An alternative to PaceEntriesElement - doesn't address all of the same
issues, but combined with PaceAggregationDocument, would address a
number of them.
http://www.intertwingly.net/wiki/pie/PaceCommentFeeds
I will start working on the template this week and will get something
posted by the weekend.
On Thu, 3 Feb 2005 11:46:14 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
James Snell wrote:
I'm just thinking ahead a bit on
On Wednesday, February 2, 2005, at 11:55 PM, James Snell wrote:
In any case, we're talking about something as simple as the name of a
single element. I just don't see any real technical value in changing
it's name. It doesn't make processing any easier. It doesn't change
any of the functional
Bill de hÓra wrote:
2. Multiple feeds can be aggregated and presented using a single data
format without having to modify the entries within those feeds to
incorporate their original feed metadata;
That sounds like a win.
3. Digital signatures can be safely applied to feeds and entries
/ Graham [EMAIL PROTECTED] was heard to say:
| Any chance of renaming atom:tagline to atom:subtitle? The two sample
| feeds posted today have the taglines ongoing fragmented essay by Tim
| Bray and WebDAV related news. Aren't taglines meant to be funny or
| catchy or clever?
+1
/ David Powell [EMAIL PROTECTED] was heard to say:
| The RELAX-NG in draft-05 seems to allow atom:feed to contain
| anyElement - this doesn't seem to be allowed by the spec's prose - is
| this a typo?
More like a thinko. I probably just assumed that anyElement could
appear in atom:feed. I'm
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are people storing entries with
the expectation that
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Graham
smime.p7s
Description: S/MIME cryptographic signature
On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote:
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are
Norman Walsh wrote:
I find the constraint that an atom:feed or atom:entry can contain at
most one atom:contributor a little odd. Suppose Tom, Dick, and Harry
work on an entry, why can only two of them get credit (one as author
and one as contributor). Why am I not allowed to indicate that they
I think your right in a way -- I agree that for 'alternate' it should
be a child element, but I hate to do that for attachment so lets drop
that I said that. Having said that I still think rel would be good to
keep.
I want to keep it simple and as close to enclosure as possible.
[-]
Ray
Section 4.15 says:
4.15 The atom:content Element
The atom:content element either contains or links to the content of
the entry. atom:entry elements MUST contain zero or one atom:content
elements.
The constraint atom:entry elements MUST contain zero or one atom:content
elements.
The test cases didn't turn out to be all that useful for my purpose,
so I turned instead to another careful reading of the spec. Here is an
updated grammar for Atom draft 0.5 modulo the constraint on
contributor which is apparently a spec error rather than a grammar
error :-)
The changes are:
*
On Feb 3, 2005, at 2:03 PM, Norman Walsh wrote:
I find the constraint that an atom:feed or atom:entry can contain at
most one atom:contributor a little odd. Suppose Tom, Dick, and Harry
work on an entry, why can only two of them get credit (one as author
and one as contributor). Why am I not
/ Tim Bray [EMAIL PROTECTED] was heard to say:
| On Feb 3, 2005, at 1:50 PM, Norman Walsh wrote:
|
| There are some constraints that the RELAX NG grammar can't practically
| enforce. Should it enforce the MUSTs of the specification or the SHOULDs?
| For example, should it allow non-XHTML elements
Norman Walsh wrote:
Some thoughts
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds become legacy? Are people storing entries with
Antone Roundy wrote:
On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote:
- It seems very likely to me that Atom will evolve over time.
- For some applications, changing the namespace name with every
version is entirely impractical. Atom may or may not be in this
category. Do feeds
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
http://groups-beta.google.com/group/bloggerDev/feed/topics.xml
On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote:
...
On Monday, Feb. 7, the Working Group's final queue rotation will
consist of all Paces open at that time. Any Paces that have obvious
holes in them (to be filled in later, more needs to go here, etc.)
will be ignored. We have had over a year of
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
Tim Bray wrote:
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
At PubSub.com, weve started
generating CAP over Atom files. By this I mean were
publishing using Atom files to encapsulate a stream of message which are
encoded using the CAP (Common Alerting Protocol) format. See:
On 4/2/05 1:54 PM, Robert Sayre [EMAIL PROTECTED] wrote:
I believe there is a proposal for a link rel=comment which would do
the job.
It wouldn't handle that example. The comments are nested. XML elements
nest pretty well. It would handle the first case... but only by
reference. You
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/2/05 2:06 PM, Graham [EMAIL PROTECTED] wrote:
If you removed the ability to have entries within the feeds in
aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally
different task.
A collection of feeds would be something like a list of blogs about a
certain topic? You
On 4/2/05 1:15 PM, Tim Bray [EMAIL PROTECTED] wrote:
3.) A List Status feed, where the only updates consist of one
collection replacing another.
RSS2 --
http://rss.netflix.com/Top100RSS
background info--
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
Just a point of data; most logos are designed to look good at a 1-to-1
aspect ratio.
On Jan 24, 2005, at 5:25 PM, Tim Bray wrote:
On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote:
+1
Should there be a suggested size for images?
A suggested aspect ratio, actually. Drat. Brent Simmons loved this
My preference would be something like
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY present
entries in any order, unless a specific ordering is required by an
extension.
(I.e., I could come up with the
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
In its present form, I want to get rid of the version attribute. That's
not to say that I don't want something with more useful semantics, on a
separate axis from the namespace.
So, +1 to the Pace.
On Feb 3, 2005, at 1:18 PM, Norman Walsh wrote:
Some thoughts
- It seems very likely to me that
+1
Welcome to the club :)
On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
Proposal
---
Remove atom:info and atom:host from The Atom Syndication Format.
Remove atom:host
---
No one seems to like the
David Powell wrote:
It looks like this might have got lost accidently when the
atom:head element was introduced. Previously Atom 0.3 said [1]:
Ordering of the element children of atom:feed element MUST NOT be
considered significant.
+1.
The order of entries in an Atom feed
Eric Scheid wrote:
I think the purpose of PaceAggregationDocument is to provide a
means to subscribe to an intermediary aggregator like pubsub, and
thus receive entries.
If that is the motivation, then I think you really should find some
other motivation.
Frankly, it is
Walter brings up an important point; has, or when will, the drafts be
compared to the requirements in the charter?
Cheers,
On Feb 2, 2005, at 8:36 PM, Walter Underwood wrote:
The charter says that Atom will work for archiving. We don't know that
it will, and it hasn't been discussed for months.
On Thursday, February 3, 2005, at 07:54 PM, Robert Sayre wrote:
2.) A Blog w/ comments, where on post serves as the root of a
collection
of other posts.
HTML--
http://www.livejournal.com/users/giant_moose/
Atom 0.3, no indication of comments--
This is now PaceNoFeedState;
http://www.intertwingly.net/wiki/pie/PaceNoFeedState
On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote:
x. Managing Feed State
Atom Processors MAY keep state (e.g., metadata in atom:head, entries)
sourced from Atom Feed Documents and combine them with other Atom
I'm OK with dropping wholefeed; I'll edit the pace to accommodate that.
WRT warning users; you realise that putting something in the user
manual, README or box of the consumer (e.g., This product does not
manage feed state.) would satisfy that requirement?
Would SHOULD make you feel better?
+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
This is excellent to see. I'm glad to see that you were not afraid to
break the syntax rules to get things started. :-) The format looks
good.
On Thu, 3 Feb 2005 21:50:51 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
At PubSub.com, we've started generating CAP over Atom files. By this I
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 to me to
+1
On Thu, 3 Feb 2005 20:24:06 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
+1
Welcome to the club :)
On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
Proposal
---
Remove atom:info and
Potential solutions that occur to me:
1. Ignore the problem
2. PaceEntriesElement could handle this
3. PaceFeedRecursive could handle this
4. PaceAtomHeadInEntry could handle this
5. PaceAggregationDocument could handle this
I honestly can't say which I prefer. Would anyone like to
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
Figured I would formalize what I've been evangelizing the past couple of days.
http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec
== Abstract ==
Defer the definition of solutions for aggregated feeds to a separate
Internet-Draft that is not a part of the Atom core syntax
On Feb 4, 2005, at 01:02, Norman Walsh wrote:
| As for the XHTML thing, I think this is going to happen all the time
(foreign
| markup in embedded XHTML) and I don't think we should try to get in
the way.
| However, I just now tried to think of some spec language to express
this and
| came up
On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote:
Figured I would formalize what I've been evangelizing the past couple
of days.
http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec
The only reason why I'm not in favor of this (in fact, it occurred to
me a little
On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.
Markup from
other vocabularies (foreign markup) can be used in Atom in
a variety of
ways. Text Constructs may contain foreign markup which SHOULD
be HTML or
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
On 4/2/05 5:07 PM, James Snell [EMAIL PROTECTED] wrote:
Defer the definition of solutions for aggregated feeds to a separate
Internet-Draft that is not a part of the Atom core syntax
specification.
+1
Because CAP is an XML format, we're using atom:content elements with
type=text/xml. In order to ensure that there is something for aggregators
to display if they don't understand CAP, we're generating atom:summary
elements that contain a textual summary of the CAP message which is in the
Antone Roundy wrote:
leaving things as they are
and deferring deciding how to handle aggregation would irreversibly
enshrine HeadInEntry into the format, which all of the current
organizational proposals are trying to replace.
That's right. Besides, HeadInEntry is trivial to do as an extension,
On 4/2/05 4:03 PM, Mark Nottingham [EMAIL PROTECTED] wrote:
This is now PaceNoFeedState;
http://www.intertwingly.net/wiki/pie/PaceNoFeedState
+1
e.
On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
Antone Roundy wrote:
leaving things as they are
and deferring deciding how to handle aggregation would irreversibly
enshrine HeadInEntry into the format, which all of the current
organizational proposals are
59 matches
Mail list logo
