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 tools. As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers to the source as well, that base is covered anyway. Putting the non-dereferencable bit in an @idref wouldn’t be all that interesting anyway, I think, unless the crawler knows how to interpret it. But if it has specific knowledge about @idref values in particular relationships, it may as well have specific knowledge about particular extension elements. So that base is covered as well in either case. So in conclusion, there’s no advantage to using atom:link as the principal vehicle for IDs here either. Seems like a trend… it’s getting very clear to me that an extension element really is The Right Choice for this thing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 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, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Comments Draft
A. Pagaltzis wrote: * 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 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 already, take a look at the version I submitted as an I-D [1]. It uses @idref for the ID reference. - James [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-00.txt
Re: Comments Draft
On 11/8/05 3:20 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers to the source as well, that base is covered anyway. I'd prefer to see atom:[EMAIL PROTECTED]in-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 -- 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. e.
Re: Comments Draft
On 5/8/05 3:07 PM, James M Snell [EMAIL PROTECTED] wrote: thr:in-reply-to id=urn:foo:1 type=application/atom+xml src=http://www.example.com/atom; / how about this instead link rel=in-reply-to 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 link is can still do something useful. e.
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. And sorry for the harsh tone. :-) ) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Comments Draft
On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote: link rel=in-reply-to 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 link is can still do something useful. Uh, consider link rel=ultimate-source-of-all-evil-STAY-AWAY href=http://example.org/evil; / What useful thing is there that software could sanely do, knowing only that something is a link? -Tim
Re: Comments Draft
On 5/8/05 9:55 PM, Tim Bray [EMAIL PROTECTED] wrote: Uh, consider link rel=ultimate-source-of-all-evil-STAY-AWAY 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 still treat it as @rel=related because the referenced resource is, uh, related. so, what could software sanely do with a [EMAIL PROTECTED]related], other than catch on fire? e.
Re: Comments Draft
On 5/8/05 7:48 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: link rel=in-reply-to 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 link is can still do something useful. No, that requires entries to be located in a feed available at a dereferencable URI because @href is not optional. So it would preclude replying to feeds delivered via SMTP, XMPP or other protocols that don¹t work like that. Ah dammit, you're right. There was blood spilled to allow entries to not be required to have an alternate too, so we can't even point at that. e.
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 engineered solution. As for specifying the source of the resource being replied to, a namespace extension inside the link element is probably the best way to go. So what we end up with is: feed ... link rel=replies href=http://www.example.com/myfeed.xml; / entry ... link rel=in-reply-to href=tag:example.com,2005:1 thread:sourcehttp://www.example.com/sourcefeed.xml;/thread:source /link /entry /feed Implementations that are not thread aware can safely drop thread:source as they won't be able to do anything useful with the in-reply-to link anyway (whether it is dereferenceable or not). While this approach may be a bit hackish, I believe that it's natural, simple and unambiguous enough to solve the problem effectively. Using the via link just seems unnatural to this purpose in that we're not expressing a relationship like The information contained here-in was received through... we're expressig The information contained here-in is a response to Via works great for the former and doesn't fit for the latter. All of the examples that have been offered built around the via mechanism just seem entirely too verbose for comfort... especially given that we're trying to optimize for optional metadata that hints at a relationship that can't be reliably confirmed (e.g. that the entity being replied to MAY exist at the specified source). Thoughts? - James A. Pagaltzis wrote: * 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 undermines link. It undermines the purpose of the link insofar as IMO the entry being replied to MUST ALWAYS be identified by its atom:id. I am strongly -1 on letting the producer choose to identify it by its network location in any way or shape. Such a location is valuable as additional information to provide, but it’s strictly optional. If 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 doesn't sound like a good rule, then I'd argue that using atom:link to identify the resource being replied to is a bad idea. I have already agreed about the fact that atom:link is not the right vehicle for carrying the atom:id, so there’s no need for you to preach to the choir. See my Thread/comment extension refactoring post about my current stance. As for overloading @rel='in-reply-to' to carry either dereferencable URIs or atom:ids, that would just needlessly require conditional checks on the consumer end. And because I’m strongly -1 on omitting the atom:id but also no longer consider atom:link to be the right place for it, the idea is triply wrong. Atom Entry Documents can move around; their IDs are eternal. True, so you could just omit @type from this link if you're concerned that your entry document might move. Or we could go with something like this: ext:in-reply-to id=... atom:link rel=found-in-entry-document href=... / atom:link rel=found-in-feed-document href=... / /ext:in-reply-to That makes the information in the nested atom:link elements inaccessible to compliant clients without threading support, and it also requires new relationships to boot. Also, note that entry-sources vs replied-to-entries is an 1:N relationship, so it would make sense to group replied-to-entries by entry-source, rather than vice versa. So then you have link rel=via type=application/atom+xml href=http://example.com/feed/; thr:source-forurn:foo:1/thr:source-for thr:source-forurn:foo:2/thr:source-for /link which properly reuses a known relationship, so that even a non-thread-aware consumer can do something interesting with the information, even if it does not understand it quite as precisely as a client with proper thread awareness. Again, see my Thread/comment extension refactoring post about my current thinking. ...okay, that last sentence suggests that what I propose just above here is a superior way to having possibly-derefencable atom:links, because you could update the found-in-entry-document link if it got out of sync with the location of the document. Otherwise, we'll have to be limited to linking to the feed in which the entry is found. I don’t see why that is an advantage specific to using the @type attribute on atom:link in the way you proposed, rather than a benefit that *any* approach for including a source URL would provide. Again, please see my other post. The
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 source of the resource being replied to, a namespace extension inside the link element is probably the best way to go. I consider it stupid blunder to have proposed using atom:link for this, not elegant and simple. You need a link and an extension element either way. So choose to squirrel away information that even clients without threading support could use inside a namespaced element, and instead put information they have no use for in a place they can access. What a mess. Why not do it the other way around? Using the via link just seems unnatural to this purpose in that we're not expressing a relationship like The information contained here-in was received through... we're expressig The information contained here-in is a response to Via works great for the former and doesn't fit for the latter. So just drop back to “related.” Either way the exposed information is sensibly usable even by clients without threading support; they don’t know *why* it’s related, but it certainly is useful to let them partake of that information. All of the examples that have been offered built around the via mechanism just seem entirely too verbose for comfort... Verbose, sure. Too verbose, how? especially given that we're trying to optimize for optional metadata that hints at a relationship that can't be reliably confirmed (e.g. that the entity being replied to MAY exist at the specified source). You are going to need a namespace any way you turn it. If you really don’t care about exposing as much information as they can use to as many clients as possible, and brevity is such a concern, then maybe it should be thr:in-reply-to src=http://example.com/atom;urn:foo:1/thr:in-reply-to which makes this a Structured instead of a Simple Extension Element, but then maybe that was unavoidable anyway. Of course, conscientous producers will drop in a link rel=related href=http://example.com/atom; / for good measure, so it’s verbose anyway. Hmm. Huh. Interesting. I like this even better than my previous proposition. D’oh. Screw sticking to Simple Extension Elements, this is better. This is *natural* – no funny business with markup inside atom:link elements. Each piece of information is available to as broad an audience as possible: threading-aware clients can correlate the “related” links to the source attributes, and non-aware clients can at least tell there is something related at the indicated resource. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 specifying the source of the
resource being replied to, a namespace extension inside the
link element is probably the best way to go.
I consider it stupid blunder to have proposed using atom:link for
this, not elegant and simple.
;-) Let's hear what you really think ;-)
thr:in-reply-to src=http://example.com/atom;urn:foo:1/thr:in-reply-to
which makes this a Structured instead of a Simple Extension
Element, but then maybe that was unavoidable anyway.
Of course, conscientous producers will drop in a
link rel=related href=http://example.com/atom; /
for good measure, so it’s verbose anyway.
ok.. ok.. I can take a hint ;-) ... according to my wife it only takes
about a couple dozen beatings to get me to think straight and listen so
I think we're making progress here ...
How does this work for you?
thr:in-reply-to id=urn:foo:1 type=application/atom+xml
src=http://www.example.com/atom; /
With a definition of:
inReplyToNonDereferenceable = element thr:in-reply-to {
attribute id { atomUri },
attribute type { atomMediaType }?,
attribute src { atomUri }?
}
inReplyToDereferenceable = element thr:in-reply-to {
attribute href { atomUri },
attribute type { atomMediaType }?,
}
This seems to tie in everything we've been discussing to this point. In
the NonDereferenceableForm, @id is used to express an opaque
identifier. @src MAY be used to specify a dereferenceable location
where the resource identified by @id might be found. In the
Dereferenceable form, @href is used to specify a location.
Used in context, it would look like:
feed
link rel=replies href=http://www.example.com/atom; /
...
entry
...
thread:in-reply-to id=tag:example.com,2005:1
type=application/atom+xml src=http://www.example.com/myotheratomfeed; /
thread:in-reply-to href=http://www.example.com/entries/1;
type=application/atom+xml /
link rel=related href=http://www.example.com/myotheratomfeed; /
link rel=related href=http://www.example.com/entries/1; /
/entry
/feed
Does this work or do I need to be taken out and flogged again?
- James
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 be the atom:id of the atom:entry. If the value of the type attribute is application/atom+xml then the href attribute MUST be the (URL/URI/IRI) of an Atom Entry Document containing the atom:entry being replied to. 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 undermines link. The primary purpose of [EMAIL PROTECTED]in-reply-to] is to identify the resource (which may be an atom:entry) being replied to. If that resource is an atom:entry, then the appropriate identifier for it is it's atom:id. If 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 doesn't sound like a good rule, then I'd argue that using atom:link to identify the resource being replied to is a bad idea. As I've said before, I think that stuffing data that happens to be a URI but may not be dereferencable into link/@href is a bad idea. If we ARE going to do it, then I think we need a way to at least hint at whether it's a dereferencable link or some other data stuffed into a link element. Here's what the spec says @type is for: On the link element, the type attribute's value is an advisory media type; it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. If @href isn't dereferenable, then the existence of @type is deceptive. I suppose it could mean when I saw it, it was in some kind of Atom document, but so what? What if the feed gets converted to RSS 2.0, the atom:id is put into guid, and I find the entry in the RSS feed? Atom Entry Documents can move around; their IDs are eternal. True, so you could just omit @type from this link if you're concerned that your entry document might move. Or we could go with something like this: ext:in-reply-to id=... atom:link rel=found-in-entry-document href=... / atom:link rel=found-in-feed-document href=... / /ext:in-reply-to Or we could just stick with what has been proposed, perhaps including what I proposed in my last message, and if they entry document moves, then oh well, the web has another broken link just as it would in what I proposed just above here or in any case where a dereferencable link was published, but the atom:id would still be valid. If after moving the entry document, one were to publish the in-reply-to link again, it would be appropriate to remove the @type attribute. ...okay, that last sentence suggests that what I propose just above here is a superior way to having possibly-derefencable atom:links, because you could update the found-in-entry-document link if it got out of sync with the location of the document. Otherwise, we'll have to be limited to linking to the feed in which the entry is found.
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 undermines link. It undermines the purpose of the link insofar as IMO the entry being replied to MUST ALWAYS be identified by its atom:id. I am strongly -1 on letting the producer choose to identify it by its network location in any way or shape. Such a location is valuable as additional information to provide, but it’s strictly optional. If 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 doesn't sound like a good rule, then I'd argue that using atom:link to identify the resource being replied to is a bad idea. I have already agreed about the fact that atom:link is not the right vehicle for carrying the atom:id, so there’s no need for you to preach to the choir. See my Thread/comment extension refactoring post about my current stance. As for overloading @rel='in-reply-to' to carry either dereferencable URIs or atom:ids, that would just needlessly require conditional checks on the consumer end. And because I’m strongly -1 on omitting the atom:id but also no longer consider atom:link to be the right place for it, the idea is triply wrong. Atom Entry Documents can move around; their IDs are eternal. True, so you could just omit @type from this link if you're concerned that your entry document might move. Or we could go with something like this: ext:in-reply-to id=... atom:link rel=found-in-entry-document href=... / atom:link rel=found-in-feed-document href=... / /ext:in-reply-to That makes the information in the nested atom:link elements inaccessible to compliant clients without threading support, and it also requires new relationships to boot. Also, note that entry-sources vs replied-to-entries is an 1:N relationship, so it would make sense to group replied-to-entries by entry-source, rather than vice versa. So then you have link rel=via type=application/atom+xml href=http://example.com/feed/; thr:source-forurn:foo:1/thr:source-for thr:source-forurn:foo:2/thr:source-for /link which properly reuses a known relationship, so that even a non-thread-aware consumer can do something interesting with the information, even if it does not understand it quite as precisely as a client with proper thread awareness. Again, see my Thread/comment extension refactoring post about my current thinking. ...okay, that last sentence suggests that what I propose just above here is a superior way to having possibly-derefencable atom:links, because you could update the found-in-entry-document link if it got out of sync with the location of the document. Otherwise, we'll have to be limited to linking to the feed in which the entry is found. I don’t see why that is an advantage specific to using the @type attribute on atom:link in the way you proposed, rather than a benefit that *any* approach for including a source URL would provide. Again, please see my other post. The approach we started with (relying mostly on @rel='in-reply-to' which I proposed) was hackish, which was okay as long as it was minimal, but is no longer tenable now that we are trying to accomplish even a bit more. My new proposition deals with all of your objections and several other issues I ran across on my own. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Comments Draft
* David Powell [EMAIL PROTECTED] [2005-07-31 02:20]: Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote: link rel=in-reply-to ... link rel=in-reply-to-feed ... / /link 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 content of the link and publish it to clients without the inner link. 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). However, sec. 6.2 implies that such elements which have the characteristics of an Extension Element but come from the Atom namespace can only be introduced by future versions of Atom and both sec. 6.4.1 and sec. 6.4.2 seem to explicitly forbid elements from the Atom namespace (although that might only be what my RNC analphabeticism suggests). So Atom processors would have to treat this markup “correctly.” The spec does not allow us to extend Atom in this way, however, and that makes sense, too: what if a future version of Atom were to allow nested links, but with semantics that differ from those in this threading extension? This is exactly the situation that the definitions in Extending Atom (sec. 6) seek to prevent. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 link rel=in-reply-to href=... link rel=source href=... / /link Nope. As I just wrote in reply to David Powell, sec. 6 of the spec forbids this, and rightly so. It reserves use of elements from the Atom namespace in places other than those specified for use by future versions of the Atom spec *only* for good reason. What if a future version of Atom were to specify nested links, but with semantics that differ from the threading extension? Suddenly, all existing Atom documents with threading clash with the spec. It’s either a regular non-nested link element with a new @rel value or an extension element with a new namespace. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 of the type attribute is application/atom+xml then the href attribute MUST be the (URL/URI/IRI) of an Atom Entry Document containing the atom:entry being replied to. This undermines the purpose of the link. Atom Entry Documents can move around; their IDs are eternal. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 person constructs (and pending bugfixes: atom:source) can be Structured Extension Elements (Metadata Elements). Child elements of atom:link are not Metadata Elements, and neither are foreign-namespaced attributes; they are undefined markup. It might be possible to get away with using undefined markup to communicate between two consenting parties, but I don't think that it forms a viable platform for extension. It falls outside of the Atom model, and it can only be preserved between publishing client, publishing server, feed publication, and aggregator if all parties either have special case support for the extension, or they preserve the document's entire Infoset intact along every step in the chain. I don't believe that the latter is a realistic expectation for Atom implementations, so it seems reasonable behaviour for a publishing server to just drop undefined content, such as foreign-namespaced attributes and atom:link children, and to just publish the link without them. Personally, I read undefined more like how C uses the word undefined. -- Dave
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 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-thread,” though I was going to suggest “thread-start.” But then I thought, we already use mail header lingo with “in-reply-to;” why not borrow another term from there and call it “references?” Yes, I know it’s not the same as the References: header. But the ultimate purpose (to trace the thread in newsreaders) is kind of similar, and more importantly, the term seems to fit the sort of relationship we’re trying to describe quite closely. If this is deemed a poor choice, then I fall back to “thread-start.” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 of which I came around to Antone’s suggested “start-of-thread,” though I was going to suggest “thread-start.” I took a look at the draft to verify whether I correctly understood what this link points to, and I think it isn't what I originally thought based on the old name root. Does this point to the feed in which the immediate parent entry was found, or to the feed in which the first entry in a thread of replies was found? If the former, which the draft seems to suggest, and which seems more useful, then start-of-thread and thread-start probably aren't such good names after all. With clarity in mind, in-reply-to-feed might be good, though it's a bit long. And problem comes to mind: if you have multiple in-reply-to links, how do you related those to their respective in-reply-to-feed links (in case they're different)? Is it possible? Dare we do something like this? (Wish we to if we dare?) link rel=in-reply-to ... link rel=in-reply-to-feed ... / /link 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 some other use, or to define this @rel value broadly enough to be applicable to other purposes. Con: * Puts an atom:link in a location not expected by apps that don't understand this extension.
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, there is no equivilent in mail terms for the purpose of the 'replies-source'. 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 where the replies come from, it’s where the entries being replied to come from. I suppose the criticism on “thread-start” and “references” is valid… but I still think that “references” is linguistically the closest to what we are trying to express. Maybe “references-source?” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 link rel=in-reply-to href=... link rel=source href=... / /link 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-reply-to to a single source location is an added bonus. Definitely works for me. A. Pagaltzis wrote: * 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 some other use, or to define this @rel value broadly enough to be applicable to other purposes. Con: * Puts an atom:link in a location not expected by apps that don't understand this extension. I like it. 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… It’s a good solution to the bikeshed of naming the relationship, and it keeps the information about the entry being replied to and its source coupled together. With a plain old @rel value, you can’t tell which ones belong together in an entry with several links of both kinds. So far I can’t really make up my mind on any one solution, but this one seems the most correct, all else considered. Regards,
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 item's link element points to (given that there is no way to uniquely identify an RSS item). link rel=in-reply-to type=text/html href=http://www.example.com/entries/1; / This is legal in the spec but is left undefined. - James Antone Roundy wrote: 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 link to the ID of the entry may not be, I'd suggest using an extension element for the possibly-non-traversable link, if for eitherwhich would leave us needing to pick a good @rel value for the traversable one. That would also keep my con point around: foo:non-traversable-reference id-of-other-entry=... link ... / /foo:non-traversable-reference ...unless it were done this way: link ... foo:non-traversable-reference id-of-other-entry=... / /link ...but doesn't quite work, because the logical relationships between the elements are entry to foo:non-traversable and foo:non-traversable to link, not entry to link and link to foo:non-traversable. I'm satisfied to live with the negative point of having a link in an unexpected place. And since I don't like non-traversable atom:links, I myself prefer foo:non-traversablelink//foo:non-traversable, though I don't expect it to be adopted.
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, the href of the link may point to the same URL that the RSS item's link element points to (given that there is no way to uniquely identify an RSS item). link rel=in-reply-to type=text/html href=http://www.example.com/entries/1; / This is legal in the spec but is left undefined. The natural choice of values when replying to an RSS 2.x item would be the guid, since it's the closest counterpart to atom:id. But if the guid is not a permalink (ie. not dereferencable), then it won't have a MIME type, just as non-dereferencable atom:id's don't have a MIME type. Both of these facts suggest that the following sentence should probably be removed from section 3: If the type attribute is omitted, it's value is assumed to be application/atom+xml. Instead, I'd suggest stating that if the type attribute is omitted, the in-reply-to link cannot be assumed to be dereferencable, and that non-dereferencable links MUST NOT have a type attribute. Editorial notes about this sentence: A type attribute value of application/atom+xml indicates that the resource being responded to is an atom:entry and that the href attribute MUST specify the value of the parent entries atom:id element. 1) parent probably isn't the best word here since in-reply-to isn't being defined in terms of parents and children. 2) entries - entry's 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 of the type attribute is application/atom+xml then the href attribute MUST be the (URL/URI/IRI) of an Atom Entry Document containing the atom:entry being replied to. Anything else could lead to inconsistencies. For example, when replying to an atom:entry that can be found in an Atom Entry Document, but whose atom:id does NOT point to that document, there would be multiple choices available for the reply link's href attribute.
Re: Comments Draft
Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote: link rel=in-reply-to ... link rel=in-reply-to-feed ... / /link 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 content of the link and publish it to clients without the inner link. I don't believe that atom:link isn't usefully extensible other than by creating new @rel values; or if you want something more powerful, use extension elements. Atom's extensibility framework has been touted as one of Atom's major advantages[1] over RSS. Nested link elements sound a bit too much like [2], but without the namespaces constraint. [1] http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared#x [2] http://blogs.law.harvard.edu/tech/rss#extendingRss -- Dave
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
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 where the replies come from, it¹s where the entries being replied to come from. original-replies-target? e.
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?” Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
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 start-of-thread. Or maybe “parent-entries?” How about mother-of-all-entries? Ha ha. The problem with parent-entries is that this link may not be pointing to the immediate parent, right?
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 be found. Antone Roundy wrote: 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 start-of-thread. Or maybe “parent-entries?” How about mother-of-all-entries? Ha ha. The problem with parent-entries is that this link may not be pointing to the immediate parent, right?
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.
