Re: Updated Comments Draft (getting closer)

* Thomas Broyer <[EMAIL PROTECTED]> [2005-08-12 23:55]: > As I read it, your proposal is about enabling threading in Atom > to allow aggregators to present entries in a tree form. > > If you want to comment on a non-Atom resource, create a new > link/@rel value or use a [EMAIL PROTECTED]"related"

Re: Updated Comments Draft (getting closer)

James M Snell wrote: The simple answer is that not everything I may want to reply too will have an ID I can reference. Suppose that what I'm responding to is an item in an RSS feed that does not contain a guid element? All I have to go off of is the URL of the RSS feed or the RSS item's li

Re: Updated Comments Draft (getting closer)

* Justin Fletcher <[EMAIL PROTECTED]> [2005-08-11 17:10]: > By all means require any reference to a Atom document to supply > an identifier, but requiring it on all references would make it > impossible to fulfill on some documents. Yeah; again, I’ve conceded the point. I still don’t particularly

Re: Updated Comments Draft (getting closer)

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

* Eric Scheid <[EMAIL PROTECTED]> [2005-08-06 05:40]: > either that or a flag that says "this is dereferenceable", but > that is ugly and doesn't let the publisher have a link with > both. > > would it be useful? google does interesting things by crawling > links, so do many other link crawling t

Re: Comments Draft

on element’s attribute. > James -- any chance of defining that in the comments draft, > alongside the 'replies' link relation. You could then simplify > the thr:in-reply-to element to just needing to handle the > thr:idref case. +0.5. If @rel='in-reply-to' is specifi

Re: Updated Comments Draft (getting closer)

* Eric Scheid <[EMAIL PROTECTED]> [2005-08-11 07:25]: > > On 11/8/05 3:05 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > > > What scenario exists wherein it would be *more* desirable to > > provide *only* a dereferencable location but *not* an ID? > > When would it be *wiser* to *rely* on a poi

Re: Updated Comments Draft (getting closer)

* James M Snell <[EMAIL PROTECTED]> [2005-08-11 08:00]: > Suppose that what I'm responding to is an item in an RSS feed > that does not contain a guid element? All I have to go off of > is the URL of the RSS feed or the RSS item's link element... > neither of which are actual ID's. Ugh. Sigh.

Re: Comments Draft

n-reply-to"]. Of course it's "related". All links in an entry point to related resources, that's the very definition of a link. We also know what the nature of the relationship is (it's in reply to that resource), so it doesn't hurt to specify that. James -- an

Re: Updated Comments Draft (getting closer)

The simple answer is that not everything I may want to reply too will have an ID I can reference. Suppose that what I'm responding to is an item in an RSS feed that does not contain a guid element? All I have to go off of is the URL of the RSS feed or the RSS item's link element... neither

Re: Comments Draft

Of course it's "related". All links in an entry point to related resources, that's the very definition of a link. We also know what the nature of the relationship is (it's in reply to that resource), so it doesn't hurt to specify that. James -- any chance of defining

Re: Updated Comments Draft (getting closer)

On 11/8/05 3:05 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > What scenario exists wherein it would be *more* desirable to > provide *only* a dereferencable location but *not* an ID? When > would it be *wiser* to *rely* on a pointer to a resource which is > always in danger of voiding, irrecove

Re: Comments Draft

* James M Snell <[EMAIL PROTECTED]> [2005-08-11 07:20]: > Yes it does work in the comments draft ;-) If you haven't done > so already, take a look at the version I submitted as an I-D > [1]. It uses @idref for the ID reference. Yeah, but that’s @thr:idref, not @atom

Re: Comments Draft

I dunno if it’d be such a great idea anyway – it just so happens that it would work for the threading extension, but I’m not sure it would be very universally useful. But yeah, it *would* work for this case… Regards, Yes it does work in the comments draft ;-) If you haven't done so

Re: Comments Draft

* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 19:35]: > ... and it's too late to write a pace with atom:idref, and > wording saying an atom:link must have at least either an > atom:href attribute or an atom:idref attribute. That is, one or > both but not neither. I dunno if it’d be such a great i

Re: Updated Comments Draft (getting closer)

* 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 -1 on making the ID optional. Why do you want to do tha

Updated Comments Draft (getting closer)

I've updated the draft of the comments extension. I think this is just about ready to submit as an I-D. http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt The major change is a refactoring of the in-reply-to and replies-source following the extensive discussion here o

Re: Comments Draft

On 5/8/05 7:48 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: >> > href="http://www.example.com/atom"; >> type="application/atom+xml" >> thread:idref="urn:foo:1" /> >> >> this way processors that have a basic understanding of what a >> is can still do something

Re: Comments Draft

On 5/8/05 9:55 PM, "Tim Bray" <[EMAIL PROTECTED]> wrote: > Uh, consider > > href="http://example.org/evil"; /> > > What useful thing is there that software could sanely do, knowing > only that something is a link? -Tim > not knowing what that particular @rel actually means, it could sti

Re: Comments Draft

On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote: http://www.example.com/atom"; type="application/atom+xml" thread:idref="urn:foo:1" /> this way processors that have a basic understanding of what a is can still do something useful. Uh, consider http://example.org/e

Re: Comments Draft

* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 08:10]: > how about this instead > >href="http://www.example.com/atom"; > type="application/atom+xml" > thread:idref="urn:foo:1" /> > > this way processors that have a basic understanding of what a > is can still

Re: Comments Draft

* James M Snell <[EMAIL PROTECTED]> [2005-08-05 07:15]: > Does this work or do I need to be taken out and flogged again? Absolutely that does work for me. (Sorry for the curt reply – I am off to catch a plane in a few minutes and won’t have ’net for a week. Tried to get this out before I am gone

Re: Comments Draft

On 5/8/05 3:07 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > src="http://www.example.com/atom"; /> how about this instead http://www.example.com/atom"; type="application/atom+xml" thread:idref="urn:foo:1" /> this way processors that have a basic understanding of wha

Re: Comments Draft

A. Pagaltzis wrote: * James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]: Personally, however, I think that the elegance and simplicity of in-reply-to and replies link rel values trumps defining them as elements in a separate namespace or an otherwise perfectly engineered solution. As for

Re: Comments Draft

* James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]: > Personally, however, I think that the elegance and simplicity > of in-reply-to and replies link rel values trumps defining them > as elements in a separate namespace or an otherwise perfectly > engineered solution. As for specifying the sou

Re: Comments Draft

I definitely appreciate all of the feedback on this. The conversation has definitely been helpful. Personally, however, I think that the elegance and simplicity of in-reply-to and replies link rel values trumps defining them as elements in a separate namespace or an otherwise perfectly engi

Re: Comments Draft

* Antone Roundy <[EMAIL PROTECTED]> [2005-08-01 18:30]: > On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote: > >This undermines the purpose of the link. > > I'd say that not being able to tell whether @href in > [EMAIL PROTECTED]"in-reply-to"] is dereferencable or not is what > undermine

Re: Comments Draft

On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote: * Antone Roundy <[EMAIL PROTECTED]> [2005-07-31 01:15]: I could add more, but instead, here's my suggestion for replacing that sentence: If the resource being replied to is an atom:entry, the value of the href attribute MUST b

Re: Comments Draft

Sunday, July 31, 2005, 4:47:44 PM, A. Pagaltzis wrote: > Strictly speaking, per Extensions To the Atom Vocabulary (sec. > 6.2), an Atom processor must treat the nested link as it would > treat any other Structured Extension Element (sec. 6.4.2). Only child elements of atom:entry, atom:feed, and

Re: Comments Draft

* Antone Roundy <[EMAIL PROTECTED]> [2005-07-31 00:30]: > I'm satisfied to live with the negative point of having a link > in an unexpected place. Except the spec forbids it. Only future versions of the Atom spec may define elements from the Atom namespace in locations that other than those curre

Re: Comments Draft

* Antone Roundy <[EMAIL PROTECTED]> [2005-07-31 01:15]: > I could add more, but instead, here's my suggestion for > replacing that sentence: > > If the resource being replied to is an atom:entry, the > value of the href attribute MUST be the atom:id of the > atom:entry. If the value o

Re: Comments Draft

* James M Snell <[EMAIL PROTECTED]> [2005-07-31 00:30]: > I agree. I'd much rather avoid introducing a new namespace for > this tho. Nested link elements if just fine I think > > > > Nope. As I just wrote in reply to David Powell, sec. 6 of the spec forbids this, and rightly so. It reserve

Re: Comments Draft

* David Powell <[EMAIL PROTECTED]> [2005-07-31 02:20]: > Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote: > > > > > > > > > I'm not at all keen on extending the link element in this way. > Atom Publishing Servers that don't know about this extension > that receive an entry co

Re: Comments Draft

On 31/7/05 7:47 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > I¹m -1 on using ³replies-source²; I should have said so more > explicitly before. To me it is non-sensical, as it parses as ³the > source of replies,² which is the opposite relationship of what > it¹s supposed to express. It¹s not wh

Re: Comments Draft

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 considerable amount of prior implementation and > > u

Re: Comments Draft

On 31/7/05 8:16 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote: > > > > > ...unless it were done this way: > > > > Why not this... While true that nesting elements does allow for more flexible cardinality, in practice will that actually hap

Re: Comments Draft

On 31/7/05 7:47 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote: > I¹m -1 on using ³replies-source²; I should have said so more > explicitly before. To me it is non-sensical, as it parses as ³the > source of replies,² which is the opposite relationship of what > it¹s supposed to express. It¹s not wh

Re: Comments Draft

Sunday, July 31, 2005, 1:09:44 AM, I wrote: > I don't believe that atom:link _isn't_ usefully extensible other than by er, that should be "is" -- Dave

Re: Comments Draft

Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote: > > > I'm not at all keen on extending the link element in this way. Atom Publishing Servers that don't know about this extension that receive an entry containing nested links from a publishing client will most likely drop the

Re: Comments Draft

On Saturday, July 30, 2005, at 04:37 PM, James M Snell wrote: One challenge is that for anything besides references to Atom entries, there is no guarantee that in-reply-to links will be non-traversable. For instance, if someone were to go and define a behavior for using in-reply-to with RSS,

Re: Comments Draft

One challenge is that for anything besides references to Atom entries, there is no guarantee that in-reply-to links will be non-traversable. For instance, if someone were to go and define a behavior for using in-reply-to with RSS, the href of the link may point to the same URL that the RSS i

Re: Comments Draft

I agree. I'd much rather avoid introducing a new namespace for this tho. Nested link elements if just fine I think Using source in this context I think avoids the potential confusion had the link appeared without nesting. The fact that it solves the problem of associating a single in

Re: Comments Draft

On Saturday, July 30, 2005, at 03:59 PM, A. Pagaltzis wrote: I’d prefer to eliminate the one contra you listed by using an extension element for this purpose (as always, nested into the link.) Of course, that means need a namespace… Given that the link to the feed is traversable, and the "lin

Re: Comments Draft

* Antone Roundy <[EMAIL PROTECTED]> [2005-07-30 23:05]: > Pro: > * Groups the two links together > * Gives us more options for what to call the inside one without > creating confusion: "source-feed", for example. It would be > nice to choose a name that's not likely to be the perfect name > for s

Re: Comments Draft

* 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 considerable amount of prior implementation and > understanding from which concepts can be drawn. However

Re: Comments Draft

osely. The 'In-Reply-To' in mail terms supplies the unique identifier used to identify the previous message. In this respect the comments draft matches up quite nicely. However, 'References' is the set of referenced messages in the source document, plus the unique identifier of t

Re: Comments Draft

On Saturday, July 30, 2005, at 02:38 PM, 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

Re: Comments Draft

* 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 which I came around to Antone’s suggested “start-of-threa

Re: Comments Draft

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. Graham wrote: On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote: * James M Snell <[EMAIL PROTECTED]> [2005-07-30 01:40]: It's really

Re: Comments Draft

On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote: * James M Snell <[EMAIL PROTECTED]> [2005-07-30 01:40]: It's really just a hint as to where original entries MIGHT be found. “originally-at?” source? Graham

Re: Comments Draft

* James M Snell <[EMAIL PROTECTED]> [2005-07-30 01:40]: > It's really just a hint as to where original entries MIGHT be > found. “originally-at?” Regards, -- Aristotle Pagaltzis //

Re: Comments Draft

Right. Nor is there any guarantee that the referenced entity will actually contain the original entry... e.g. it's possible that it could point to a feed that has been updated such that the original entry has already moved off of it. It's really just a hint as to where original entries MIGHT

Re: Comments Draft

On Friday, July 29, 2005, at 02:41 PM, A. Pagaltzis wrote: * Antone Roundy <[EMAIL PROTECTED]> [2005-07-29 02:40]: On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote: "root" is now called "replies-source"... which is a horrible name but I'm not sure what else to call it How about

Re: Comments Draft

* Antone Roundy <[EMAIL PROTECTED]> [2005-07-29 02:40]: > On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote: > > "root" is now called "replies-source"... which is a horrible > > name but I'm not sure what else to call it > > > How about "start-of-thread". Or maybe “parent-entries?” R

Re: Comments Draft

On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote: * "root" is now called "replies-source"... which is a horrible name but I'm not sure what else to call it How about "start-of-thread".

Comments Draft

Here is the draft. I have NOT yet submitted it for publication. I am offering it here for review purposes. Please take a look and send me your comments. http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt Major change: I've renamed the various link rel values: * "in-r