Re: Atom Comments Extension

2005-10-14 Thread Justin Fletcher
On Thu, 13 Oct 2005, A. Pagaltzis wrote: Hi James, * James M Snell <[EMAIL PROTECTED]> [2005-09-08 06:45]: If anyone has any further comments on the draft, please let me know. I am alarmed that this draft does *not even once* explicitly mention the fact that idrefs are expected to be derive

Re: ACE - Atom Common Extensions Namespace

2005-10-02 Thread Justin Fletcher
On Sun, 2 Oct 2005, James M Snell wrote: Justin Fletcher wrote: Some questions spring to mind... What should implementors do when both feed history and ace namespaced elements with equivilent meanings are present - which of the two should resolve this conflict ? Same thing that

Re: ACE - Atom Common Extensions Namespace

2005-10-02 Thread Justin Fletcher
On Sun, 2 Oct 2005, James M Snell wrote: Bill de hÓra wrote: James M Snell wrote: As I've been going through the effort of defining a number of Atom extensions, I've consistently come back to the thought that it would be interesting to explore the creation of a "Common Extensions Namespace"

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

2005-08-22 Thread Justin Fletcher
On Mon, 22 Aug 2005, James M Snell wrote: Justin Fletcher wrote: I'm a little confused by all this discussion of never-ending XML documents, mainly because my understanding is that without the well-formedness checks the content might as well be free form, and the elements withi

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

2005-08-22 Thread Justin Fletcher
On Mon, 22 Aug 2005, Tim Bray wrote: On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: 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. Ahh, I had thought this was a more dedicated ping traffic

Re: Updated Comments Draft (getting closer)

2005-08-11 Thread Justin Fletcher
On Thu, 11 Aug 2005, A. Pagaltzis wrote: > > * James M Snell <[EMAIL PROTECTED]> [2005-08-09 07:25]: > > The second feed illustrates the two forms of the in-reply-to > > element. The dereferenceable form uses the href attribute to > > locate the entity being responded to. > > I am still strongly

Re: Comments Draft

2005-07-30 Thread Justin Fletcher
On Sat, 30 Jul 2005, A. Pagaltzis wrote: > > * Justin Fletcher <[EMAIL PROTECTED]> [2005-07-30 23:25]: > > I'm quite happy with 'replies-source' because it does not > > indComparing to mail seems to be a reasonable thing to do - > > mail has a co

Re: Comments Draft

2005-07-30 Thread Justin Fletcher
On Sat, 30 Jul 2005, A. Pagaltzis wrote: > * James M Snell <[EMAIL PROTECTED]> [2005-07-30 18:10]: > > Yeah, source is likely the most logical choice, but I didn't > > want to confuse folks with a link @rel="source" that has a > > different meaning from atom:source. > > An argument by way of whic

Re: atom:author clarification

2005-05-23 Thread Justin Fletcher
On Tue, 24 May 2005, Eric Scheid wrote: > > On 24/5/05 4:14 AM, "Justin Fletcher" <[EMAIL PROTECTED]> wrote: > > As I understand it, the intention is that atom:author within atom:feed > > applies to all child atom:entry elements; that is, the value is inherited

atom:author clarification

2005-05-23 Thread Justin Fletcher
Hiya, I'm trying to understand the intention of the draft, together with some of the comments posted here recently. I've only been looking at Atom for a couple of days so I may be misunderstanding. As I understand it, the intention is that atom:author within atom:feed applies to all child atom:e