Re: If you want "Fat Pings" just use Atom!

* Sam Ruby <[EMAIL PROTECTED]> [2005-08-22 06:45]: > SAX is a popular API for dealing with streaming XML (and there > are a number of "pull parsing" APIs too). Of course – using a DOM parser is impossible with either approach anyway. > With a HTTP client library and SAX, the "absolute simplest >

Re: If you want "Fat Pings" just use Atom!

Joe Gregorio wrote: > Why not POST the Atom Entry, ala the Atom Publishing Protocol? Essentially, LiveJournal is making this data available to anybody who wishes to access it, without any need to register or to invent a unique API. I can, and have, accessed the LiveJournal stream from behind bot

Re: If you want "Fat Pings" just use Atom!

A. Pagaltzis wrote: > * Bob Wyman <[EMAIL PROTECTED]> [2005-08-22 01:05]: > >>What do you think? Is there any conceptual problem with >>streaming basic Atom over TCP/IP, HTTP continuous sessions >>(probably using chunked content) etc.? > > I wonder how you would make sure that the document is >

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

* James M Snell <[EMAIL PROTECTED]> [2005-08-22 05:30]: > Second note to self: After thinking about this a bit more, I > would also need a way of specifying a null license (e.g. the > lack of a license). For instance, what if an entry that does > not contain a license is aggregated into a feed tha

Re: If you want "Fat Pings" just use Atom!

Bob Wyman wrote: Basically, there are many really easy ways that one can handle streams of Atom entries. You could prepend an empty feed to the head of the stream, you could use "virtual" end-tags, you could just send entries and rely on the receiver to wrap them up as required, etc...

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

A. Pagaltzis wrote: * Robin Cover <[EMAIL PROTECTED]> [2005-08-22 05:05]: On Mon, 22 Aug 2005, A. Pagaltzis wrote: That issue is inheritance. atom:author is the only precedent for it in Atom. If "it" in "only precedent for it" refers to inhertance, can you explain the sense i

Re: If you want "Fat Pings" just use Atom!

* Bob Wyman <[EMAIL PROTECTED]> [2005-08-22 05:25]: > If Atom provides all we need, lets not do something else unless > there is a *very* good argument to do so. I’m not inventing anything. Atom Entry Documents are part of the spec and Atom Feed Documents may legally be empty. And a consumer of

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Bob Wyman wrote: Aristotle Pagaltzis wrote: That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a "License" that you can associate with Atom feeds and entries. However, scoping becomes very important in this

RE: If you want "Fat Pings" just use Atom!

Aristotle Pagaltzis wrote: > Shades of SGML. No! No! Not that! :-) He continues with: > ... many good points Basically, there are many really easy ways that one can handle streams of Atom entries. You could prepend an empty feed to the head of the stream, you could use "virt

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

* Robin Cover <[EMAIL PROTECTED]> [2005-08-22 05:05]: > On Mon, 22 Aug 2005, A. Pagaltzis wrote: > > That issue is inheritance. > > > > atom:author is the only precedent for it in Atom. > > If "it" in "only precedent for it" refers to inhertance, can > you explain the sense in which "atom:author

RE: If you want "Fat Pings" just use Atom!

Joe Gregorio wrote: > Why can't you keep that socket open, that is the default > behavior for HTTP 1.1. In some applications, HTTP 1.1 will work just fine. However, HTTP doesn't add much to the high volume case. It also costs a great deal. For instance, every POST requires a response. This

Re: If you want "Fat Pings" just use Atom!

* Bob Wyman <[EMAIL PROTECTED]> [2005-08-22 04:00]: > Basically, what you do is consider the open tag to have a > virtual closure and use it primarily as a carrier of stream > metadata. Shades of SGML… > You could certainly do that, however, you will inevitably want > to pass across some stream

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

A. Pagaltzis wrote: And with that, getting back to your question, the answer seems pretty clear: it depends on whether the extension element is more like atom:contributor, ie defines a property which an entry may or may not have, or more like atom:author, ie defines a property that every entry

Re: If you want "Fat Pings" just use Atom!

Bob Wyman wrote: Joe Gregorio wrote: Why not POST the Atom Entry, ala the Atom Publishing Protocol? This would be an excellent idea if what we were talking about was a low volume site. However, a site like LiveJournal generates hundreds of updates per minute. Right now, on a S

Re: If you want "Fat Pings" just use Atom!

On 8/21/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > Joe Gregorio wrote: > > Why not POST the Atom Entry, ala the Atom Publishing Protocol? > This would be an excellent idea if what we were talking about was a > low volume site. However, a site like LiveJournal generates hundreds of > update

RE: Extensions at the feed level (Was: Re: geolocation inatom:author?)

Eric Scheid wrote: > It's an interesting problem. A pity now that the idea of segregating > entry-defaults at the feed level didn't get sufficient momentum. > But what if there was an widely known extension developed for just > this purpose -- providing entry metadata at the feed level. Possibly >

RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Aristotle Pagaltzis wrote: > That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a "License" that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculi

RE: If you want "Fat Pings" just use Atom!

Aristotle Pagaltzis wrote: > I wonder how you would make sure that the document is > well-formed. Since the stream never actually ends and there > is no way for a client to signal an intent to close the connection, > the at the top would never actually be accompanied by a > at the bottom.

RE: If you want "Fat Pings" just use Atom!

Joe Gregorio wrote: > Why not POST the Atom Entry, ala the Atom Publishing Protocol? This would be an excellent idea if what we were talking about was a low volume site. However, a site like LiveJournal generates hundreds of updates per minute. Right now, on a Sunday evening, they are upda

Re: If you want "Fat Pings" just use Atom!

Why not POST the Atom Entry, ala the Atom Publishing Protocol? -joe -- Joe Gregoriohttp://bitworking.org

Re: If you want "Fat Pings" just use Atom!

* Bob Wyman <[EMAIL PROTECTED]> [2005-08-22 01:05]: > What do you think? Is there any conceptual problem with > streaming basic Atom over TCP/IP, HTTP continuous sessions > (probably using chunked content) etc.? I wonder how you would make sure that the document is well-formed. Since the stream n

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

On 22/8/05 10:28 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > What should an aggregate feed generator like PubSub do when it finds > an entry in a feed that contains unscoped extensions as children of the > feed? It's an interesting problem. A pity now that the idea of segregating entry-default

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

* Paul Hoffman <[EMAIL PROTECTED]> [2005-08-22 01:00]: > The crux of the question is: what happens when an extension > that does not specify the scope appears at the feed level? Let me step back to look at the larger issue for a moment. That issue is inheritance. atom:author is the only precede

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

On 22/8/05 9:22 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote: >> The crux of the question is: what happens when an extension that does >> not specify the scope appears at the feed level? > > I'm not sure why this question is interesting. What sort of > application would need to know? a search e

RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Paul Hoffman wrote: > The crux of the question is: what happens when an extension that > does not specify the scope appears at the feed level? Robert Sayre asked: > I'm not sure why this question is interesting. What sort of > application would need to know? I ask: What should an aggregat

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

On 8/21/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > > At 3:35 PM -0700 8/21/05, James M Snell wrote: > >IMHO, it depends entirely on how the extension is defined. The > >various extensions I have put together (e.g. comments, expires, > >etc), the metadata can be placed on the feed/source level

Re: xml:base abuse

Sjoerd Visscher wrote: > > Sam Ruby wrote: > URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform >>> >>> Ah, ok, I missed that. (Just to be sure, you added www yourself, or is >>> there a link to the feed somewhere wit

If you want "Fat Pings" just use Atom!

The subject of “Fat Pings” or full content streaming from blogs has come up on the FeedMesh list and in a proposal by Brad Fitzpatrick of LiveJournal. I’ve responded to the FeedMesh list suggesting that the best way to move forward is to simply use Atom feeds rather than invent new formats.

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

At 3:35 PM -0700 8/21/05, James M Snell wrote: IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as ). On

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Paul Hoffman wrote: At 7:24 PM +0100 8/21/05, Peter Robinson wrote: I do something similar, intending it to mean "the location of the items described by this feed" (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative

RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)

At 5:10 PM -0400 8/21/05, Bob Wyman wrote: I believe the correct answer is "e": e) Unless otherwise specified, this information pertains to the feed only. Er, right. Change that list to: a) this information pertains to each entry (unless otherwise specified) b) this information pertains to

RE: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Paul Hoffman asked: > Does an informative extension that appears at the feed level > (as compared to in entries) indicate: > a) this information pertains to each entry > b) this information pertains to the feed itself > c) this information pertains to each entry and to the feed itself > d) complet

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

* Paul Hoffman <[EMAIL PROTECTED]> [2005-08-21 21:55]: > Ah, I had missed that. This leads to a question for the mailing > list. Does an informative extension that appears at the feed > level (as compared to in entries) indicate: > > a) this information pertains to each entry > > b) this informa

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

Sunday, August 21, 2005, 8:46:54 PM, Paul Hoffman wrote: > At 7:24 PM +0100 8/21/05, Peter Robinson wrote: >>I do something similar, intending it to mean "the location of the items >>described by this feed" (when there is a single location). > Ah, I had missed that. This leads to a question for

Extensions at the feed level (Was: Re: geolocation in atom:author?)

At 7:24 PM +0100 8/21/05, Peter Robinson wrote: I do something similar, intending it to mean "the location of the items described by this feed" (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears a

Re: geolocation in atom:author?

Paul Hoffman <[EMAIL PROTECTED]> wrote: > At 12:17 AM +1000 8/22/05, Eric Scheid wrote: > > >In this example, can anything intelligent be said about the various > >different locations? Is my intent clear, or are there clear ambiguities? > > > > > > ... > > location#1 > > > > foo > >

Re: xml:base abuse

Sam Ruby wrote: URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform Ah, ok, I missed that. (Just to be sure, you added www yourself, or is there a link to the feed somewhere with www in it?) Your feed is available from both

Re: xml:base abuse

Sjoerd Visscher wrote: > > Sam Ruby wrote: > >> Sjoerd Visscher wrote: >> >>> Sam Ruby wrote: >>> >>> Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 >>> >>> >>> The explanation in the documentation[1] is perfect. And it says "As the >>> current xml:ba

Re: geolocation in atom:author?

At 12:17 AM +1000 8/22/05, Eric Scheid wrote: In this example, can anything intelligent be said about the various different locations? Is my intent clear, or are there clear ambiguities? ... location#1 foo location#2 foo location#3 location#4

geolocation in atom:author?

In this example, can anything intelligent be said about the various different locations? Is my intent clear, or are there clear ambiguities? ... location#1 foo location#2 foo location#3 location#4 ... ... e.

Re: xml:base abuse

A. Pagaltzis wrote: What do you think about what I said? Is @rel='self' being a same-document reference a problem? No. As long as xml:base is the same as the document URI. One thing to note is that when retrieving the document from the location @rel='self' refers to, as the external base URI

Re: xml:base abuse

* Sjoerd Visscher <[EMAIL PROTECTED]> [2005-08-21 14:50]: >> Except it’s a @rel='self' link, so you really do want it to >> resolve to . > > This was about the link in the solution in > http://www.feedvalidator.org/docs/warning/SameDocumentReference.html > which

Re: xml:base abuse

A. Pagaltzis wrote: * Sjoerd Visscher <[EMAIL PROTECTED]> [2005-08-21 13:40]: Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: http://example.com/blog/feed.atom"; /> This is also more consistent with the explanation. Except

Re: xml:base abuse

* Sjoerd Visscher <[EMAIL PROTECTED]> [2005-08-21 13:40]: > Regarding the solution, my first suggestion would be to change > the xml:base to reference the atom document, e.g.: > > http://example.com/blog/feed.atom"; /> > > This is also more consistent with the explanation. Except it’s a @rel=

Re: xml:base abuse

Sam Ruby wrote: Sjoerd Visscher wrote: Sam Ruby wrote: Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 The explanation in the documentation[1] is perfect. And it says "As the current xml:base in effect does not match the URI of the document", but this is not

Re: xml:base abuse

Sjoerd Visscher wrote: > Sam Ruby wrote: > >> Sjoerd, I'd be interested in your comments on this: >> >> http://tinyurl.com/9o6y2 > > The explanation in the documentation[1] is perfect. And it says "As the > current xml:base in effect does not match the URI of the document", but > this is not the

Re: xml:base abuse

Sam Ruby wrote: Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 The explanation in the documentation[1] is perfect. And it says "As the current xml:base in effect does not match the URI of the document", but this is not the case in my feed, so I'm not sure why y