Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent)

2005-02-03 Thread Eric Scheid
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

Re: PaceCollection

2005-02-03 Thread =?ISO-8859-1?Q?Bill_de_h=D3ra?=
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

Re: PaceEntriesElement

2005-02-03 Thread =?ISO-8859-1?Q?Bill_de_h=D3ra?=
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

Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-03 Thread Danny Ayers
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

Re: PaceMustBeWellFormed

2005-02-03 Thread Julian Reschke
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

PaceCommentFeeds posted

2005-02-03 Thread Antone Roundy
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

Re: Thinking ahead: Atom Extension Proposals on the Wiki?

2005-02-03 Thread James Snell
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

Re: PaceCollection

2005-02-03 Thread Antone Roundy
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

Re: PaceEntriesElement

2005-02-03 Thread Robert Sayre
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

Re: tagline - subtitle

2005-02-03 Thread Norman Walsh
/ 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

Re: RELAX-NG bug in draft-05?

2005-02-03 Thread Norman Walsh
/ 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

PaceRemoveVersionAttr

2005-02-03 Thread Norman Walsh
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

Re: PaceRemoveVersionAttr

2005-02-03 Thread Graham
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

RELAX NG Grammar question

2005-02-03 Thread Norman Walsh
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 inside a Content Construct with the type 'XHTML'? Be seeing you,

Re: PaceRemoveVersionAttr

2005-02-03 Thread Antone Roundy
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

Re: Exactly one atom:contributor?

2005-02-03 Thread Robert Sayre
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

Re: PaceLinkEnclosure needs help

2005-02-03 Thread Ray Slakinski
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

atom:content in atom:entry

2005-02-03 Thread Norman Walsh
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.

Re: atom:content in atom:entry

2005-02-03 Thread Robert Sayre
Norman Walsh wrote: 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

Updated Atom grammar

2005-02-03 Thread Norman Walsh
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: *

Re: Exactly one atom:contributor?

2005-02-03 Thread Tim Bray
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

Re: RELAX NG Grammar question

2005-02-03 Thread Norman Walsh
/ 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

Re: PaceRemoveVersionAttr

2005-02-03 Thread Sam Ruby
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

Re: PaceRemoveVersionAttr

2005-02-03 Thread Sam Ruby
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

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Tim Bray
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 organization and abstraction

2005-02-03 Thread Tim Bray
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 across the network,

Re: Call for final Paces for consideration: deadline imminent

2005-02-03 Thread Tim Bray
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

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
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

Re: Organization Use Cases

2005-02-03 Thread Robert Sayre
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--

CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread Bob Wyman
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:

Re: Organization Use Cases

2005-02-03 Thread Eric Scheid
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

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
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

Re: PaceAggregationDocument (was: On organization and abstraction)

2005-02-03 Thread Eric Scheid
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

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread Eric Scheid
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--

Re: On organization and abstraction

2005-02-03 Thread Tim Bray
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

Re: PaceEnclosuresAndPix status

2005-02-03 Thread Mark Nottingham
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

Re: Posted PaceEntryOrder (was Entry order)

2005-02-03 Thread Mark Nottingham
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

RE: On organization and abstraction

2005-02-03 Thread Bob Wyman
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

Re: PaceRemoveVersionAttr

2005-02-03 Thread Mark Nottingham
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

Re: PaceRemoveInfoAndHost

2005-02-03 Thread Mark Nottingham
+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

RE: Entry order

2005-02-03 Thread Bob Wyman
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

RE: PaceAggregationDocument (was: On organization andabstraction)

2005-02-03 Thread Bob Wyman
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

Re: Call for final Paces for consideration: deadline imminent

2005-02-03 Thread Mark Nottingham
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.

Re: Organization Use Cases

2005-02-03 Thread Antone Roundy
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--

Re: Feed State [was: Work Queue Rotation #16]

2005-02-03 Thread Mark Nottingham
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

Re: PaceFeedState status

2005-02-03 Thread Mark Nottingham
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?

Re: On organization and abstraction

2005-02-03 Thread Mark Nottingham
+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

Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread James Snell
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

Re: On organization and abstraction

2005-02-03 Thread James Snell
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

Re: PaceRemoveInfoAndHost

2005-02-03 Thread James Snell
+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

Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)

2005-02-03 Thread James Snell
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

Re: On organization and abstraction

2005-02-03 Thread Robert Sayre
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

New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell
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

Re: RELAX NG Grammar question

2005-02-03 Thread Henri Sivonen
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

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Antone Roundy
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

Re: PaceExtendingAtom

2005-02-03 Thread Tim Bray
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

Re: On organization and abstraction

2005-02-03 Thread Antone Roundy
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

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Eric Scheid
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

Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)

2005-02-03 Thread Eric Scheid
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

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread Robert Sayre
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,

Re: Feed State [was: Work Queue Rotation #16]

2005-02-03 Thread Eric Scheid
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.

Re: New Pace: PaceAggregationInSeparateSpec

2005-02-03 Thread James Snell
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