Re: Feed Thread Draft Updated
Saturday, April 22, 2006, 1:53:26 AM, James M Snell wrote:
So this is what I've got:
count = element thr:count {
attribute xml:base { atomUri }?,
attribute ref { atomUri }?,
attribute updated { date-time }?,
( nonNegativeInteger )
}
I think that is ok.
Aristotle's suggestion is ok, in that it saves a bit of typing in the
common case where there is only one link - but in the case where there
is more than one link, a combined count seems pretty useless: if there
are multiple comment links, then either the consumer can cope with
them and process both the links and counts, or the consumer can't cope
with them and can only process the combined count - but the count
alone without any links to reach the comments isn't very useful, so
why bother with it - consumers that can cope with multiple comments
links will be able to manage addition of the counts if necessary.
A variation would be to go with your proposal, but to say that ref is
optional if there is only one comments link, but would that be
fragile? People would have to remember to fix things up if they added
extra comment links - but is that going to be a common occurrence?
And implementations that add comment links will presumably be aware of
the semantics of comment links, and will therefore know about the need
to add missing refs?
Anyway, I think that any of these options is better than the current
situation.
The value of ref is the href of a replies link appearing in the
entry/feed/source. Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI.
xml:base always gets nasty, but I don't see it as being a big problem
in this case.
The updated spec would have an appendix that would explain that previous
versions of the extension defined the attributes and that some
implementations have been deployed that use the attributes. The spec
will indicate that those attributes are deprecated in favor of the
thr:count element but that feed consumers have the discretion of whether
or not to support them.
Maintaining compatibility with an expired Internet Draft? I don't
really support that. Is it really needed:
Stage 1: Implementation X has no support for FTE
Stage 2: Implementation X supports obsolete draft of FTE
Stage 3: Implementation X supports final version of FTE
Nobody is going to consider the obsolete form to be invalid. All that
would happen if consumers don't support it, is that they won't see the
thread counts. This isn't a big deal, as before the implementations
had implemented support for FTE consumers wouldn't see the thread
counts anyway. Eventually those implementations that support the
obsolete form will be updated, and consumers will be able to process
the thread counts.
(I think the moral of this story is to, in future, not to specify
IANA-namespaced link rel until a specification has been finalised.
During development there are bound to be changes, and IANA links don't
allow versioning, or DO-NOT-DEPLOY banners in the URI (like the one we
put in Atom draft namespace). Although, to be honest, I'm amazed if
there is any real reluctance to make breaking changes to an Internet
Draft.)
Does this work?
- James
--
Dave
Re: Feed Thread Draft Updated
That, or You lied to me when you told me this was a web feed! (credit: 'href (http://plasmasturm.org/code/)) A friend of mine in a compiler writing class produced a compiler with one error message 'you lied to me when you told me this was a program'. – Pete Fenelon On 4/21/06, James M Snell [EMAIL PROTECTED] wrote: The feedvalidator really does need a ValidButPositivelyIdiotic warning. - James Eric Scheid wrote: On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote: Where that gets nasty, of course, is when the href is relative and xml:base is being used to set the Base URI. Publisher would need to make sure that the href/ref combo match up properly Would this be considered a match? link rel=replies href=comments xml:base=/06/04/21/blah/ / thr:count ref=/06/04/21/blah/comments updated=...5/thr:count You just know there'll be a few idiots that will try that on. e. -- M:D/ M. David Peterson http://www.xsltblog.com/
RE: Feed Thread Draft Updated
Returning from the beyond to cast a vote. James M Snell wrote: a. Status quo. Leave things the way they are in the current draft +1 b. Drop thr:count and thr:when from the spec. -1 I have yet to hear personally an argument compelling to me to believe why these elements should be eliminated. Unless they violate an existing specification, which they don't to my knowledge, I find these incredibly useful. Furthermore, I am pretty sure James added these at [partially] my request, so I feel it important for me to provide the use case that was the catalyst for this feature. A Six Apart partner (Friendster in this case) desired a way of keeping tabs on what posts within TypePad were getting new comments, with the purpose of being able to email its subscribers saying - You have a new comment on your blog, or your friend has a new comment on their blog. On one hand this partner could just grab each comments feed individually and crunch the stats they needed that way, but their IDEAL solution involved them being able to fetch a single document that contained this information. The alternative: fetching a feed, then fetching the comment feed for each entry, parsing those feeds and determining a) when the last comment was, and how many comments there are in total seemed like overkill to me And I have to agree. There should be no need for a client to have to fetch and parse so much XML on its own to get such simple meta data. Thus my desire to have these added. What was especially interesting about our implementation was that we did not implement comment feeds themselves. We implemented comment meta data only. You will not find comment feeds on Friendster, but you will find an easy way for a client to extract meaningful data about comment activity from the system. It was a light weight solution with minimal impacts for us and Friendster alike. Example: http://byrnereese.blogs.friendster.com/my_blog/atom.xml c. Create a new replies extension element -0.5 Given that we have an implementation in the wild I tend to say, no, I like it as-is. But I have no grounds to hold up progress on this draft because of Six Apart's preference. But 1.5 million blogs using the replies link relation ain't insignificant. :) d. Create a supplemental extension element +0
Re: Feed Thread Draft Updated
James M Snell wrote: Maybe, but given that WG messed up in not making the link element formally extensible, it's not likely to be pretty. Nice one. a. Status quo. Leave things the way they are in the current draft. -1. James M Snell wrote: None of the implementors I'm aware of are currently making use of multiple replies link relations It doesn't work in the Windows Feed API, client implementors haven't been too excited about it, and it's not based on existing practice. I don't really have a problem parsing it, I just don't know what I would do with a group of those figures, or why it's even needed. b. Drop thr:count and thr:when from the spec. + 0.5. thr:when seems pretty useless. d. Create a supplemental extension element +1. Robert Sayre
Re: Feed Thread Draft Updated
* James M Snell [EMAIL PROTECTED] [2006-04-13 09:05]: Maybe, but given that WG messed up in not making the link element formally extensible, it's not likely to be pretty. Yes. WGs mess up. It’s just life. In a perfect world, this would be different, but Atom took long enough to ship. What we shipped feels very solid and robust to me, despite the occasional hole or oversight. So let’s just accept that what we have is somewhat imperfect, and try to get as close to pretty as we can within the constraints. Also, keep in mind that the uglier and more complicated the correct approach looks, the more implementors are going to gravitate towards less-than-correct approaches that meet their immediate needs. I know. a. Status quo. Leave things the way they are in the current draft with a firm warning to implementors that not all atom impls will be capable of supporting them. -0.5. As David and Byrne pointed out, having this information is clearly useful, otherwise these attributes would not be part of the spec; so it’s worth making an effort to make them available. b. Drop thr:count and thr:when from the spec. +0 Though -0.5 if that’s all that would happen. *Some* mechanism for providing this information should be available. c. Create a new replies extension element thr:replies href=... type=... hreflang=... title=... count=... when=... / +0.5 d. Create a supplemental extension element d1: link rel=replies href=... / thr:replies ref=... count=... when=... / Where the ref attribute in thr:replies / is a unique identifier that can be matched to the resource linked by the replies link. If only a single replies link is specified, ref can be omitted. There could be one thr:replies for each replies link. +0.5 I’d instead propose a `thr:count` element with content, with attributes `ref` and `updated` (`when` is too vague, IMO; I’d prefer names suggestive of RFC4287 vernacular, particularly when the semantics are comparable). If `ref` is omitted, this is a global reply count. If it is present, this is a local reply count for that resource, and the content of the `ref` attribute must be identical with the `href` attribute of the corresponding link. `updated` is, of course, optional. A single global reply count is always permitted, in addition to local reply counts, of which there may be exactly one per resource referenced in a `replies` link. This reduces the typical use case to a single Simple Extension Element: thr:count5/thr:count This accomodates developers with modest immediate needs neatly. The most complex scenario then looks something like this, where there are several additional Structured Extension Elements: link rel=replies href=http://example.org/06/04/21/blah/comments; type=application/atom+xml / link rel=replies href=http://example.org/06/04/21/blah/trackbacks; type=application/atom+xml / thr:count ref=http://example.org/06/04/21/blah/comments; updated=2006-04-22T00:50:55+02004/thr:count thr:count ref=http://example.org/06/04/21/blah/trackbacks; updated=2006-04-21T22:21:37+02001/thr:count thr:count5/thr:count It’s somewhat ugly, but I think I can stomach it. How does that look? So far I’m not decided about whether there should be any language to suggest some interpretation of a discrepance between a global reply count and the sum of local reply counts, but I’m leaning strongly towards no. Since local reply counts would not have to be given for *every* resource, any constraint that the sum of local replies match up with global reply count would have to be qualified to apply only when local reply counts are present for *all* linked `replies` resources. So not only is it questionable whether such a constraint would really be useful in the first place, rather than an unnecessary burden, but it also would be complex, and yet feeble. That makes it seem like a bad idea. d2: link rel=replies href=... / thr:replies count=... when=... / only one thr:replies would be specified regardless of the number of replies links. count would be reflective of the total number of known replies across all links. -1. Having per-link information allows mapping scenarios more complex than the weblog model, such as a Usenet-ish landscape of multiple related, but independent distributed feeds. I’d rather not throw those out. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread Draft Updated
grumble ... I'm not really happy with it but this would work.
To be absolutely honest, David's comments here [1] really got me
thinking. It's definitely worth a read and alone was sufficient to sway
me on this. I don't like it; the use of the supplemental element is
ugly, but it's better than what's currently out there (e.g. slash:count)
and at the very least preserves the use case.
So this is what I've got:
count = element thr:count {
attribute xml:base { atomUri }?,
attribute ref { atomUri }?,
attribute updated { date-time }?,
( nonNegativeInteger )
}
The value of ref is the href of a replies link appearing in the
entry/feed/source. Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI. Publisher
would need to make sure that the href/ref combo match up properly, e.g.:
link rel=replies
href=comments
xml:base=/06/04/21/blah/ /
thr:count ref=comments
xml:base=/06/04/21/blah/
updated=...5/thr:count
The updated spec would have an appendix that would explain that previous
versions of the extension defined the attributes and that some
implementations have been deployed that use the attributes. The spec
will indicate that those attributes are deprecated in favor of the
thr:count element but that feed consumers have the discretion of whether
or not to support them.
Does this work?
- James
[1]http://www.oreillynet.com/xml/blog/2006/04/if_its_not_broken_dont_fix_it.html#comment-25193
A. Pagaltzis wrote:
[snip]
I’d instead propose a `thr:count` element with content, with
attributes `ref` and `updated` (`when` is too vague, IMO; I’d
prefer names suggestive of RFC4287 vernacular, particularly when
the semantics are comparable). If `ref` is omitted, this is a
global reply count. If it is present, this is a local reply count
for that resource, and the content of the `ref` attribute must be
identical with the `href` attribute of the corresponding link.
`updated` is, of course, optional.
A single global reply count is always permitted, in addition to
local reply counts, of which there may be exactly one per
resource referenced in a `replies` link.
This reduces the typical use case to a single Simple Extension
Element:
thr:count5/thr:count
This accomodates developers with modest immediate needs neatly.
The most complex scenario then looks something like this, where
there are several additional Structured Extension Elements:
link rel=replies href=http://example.org/06/04/21/blah/comments;
type=application/atom+xml /
link rel=replies href=http://example.org/06/04/21/blah/trackbacks;
type=application/atom+xml /
thr:count ref=http://example.org/06/04/21/blah/comments;
updated=2006-04-22T00:50:55+02004/thr:count
thr:count ref=http://example.org/06/04/21/blah/trackbacks;
updated=2006-04-21T22:21:37+02001/thr:count
thr:count5/thr:count
It’s somewhat ugly, but I think I can stomach it.
How does that look?
So far I’m not decided about whether there should be any language
to suggest some interpretation of a discrepance between a global
reply count and the sum of local reply counts, but I’m leaning
strongly towards no. Since local reply counts would not have to
be given for *every* resource, any constraint that the sum of
local replies match up with global reply count would have to be
qualified to apply only when local reply counts are present for
*all* linked `replies` resources. So not only is it questionable
whether such a constraint would really be useful in the first
place, rather than an unnecessary burden, but it also would be
complex, and yet feeble. That makes it seem like a bad idea.
d2:
link rel=replies href=... /
thr:replies count=... when=... /
only one thr:replies would be specified regardless
of the number of replies links. count would be
reflective of the total number of known replies
across all links.
-1. Having per-link information allows mapping scenarios more
complex than the weblog model, such as a Usenet-ish landscape of
multiple related, but independent distributed feeds. I’d rather
not throw those out.
Regards,
Re: Feed Thread Draft Updated
* James M Snell [EMAIL PROTECTED] [2006-04-22 03:05]: grumble ... I'm not really happy with it but this would work. That’s roughly how I feel about it. :-) It has in fact been the theme all throughout the Thread extension development discussion… To be absolutely honest, David's comments here [1] really got me thinking. Yeah, same here. Credit for my proposition really goes to him, because his arguments about this matter (not just there, but taken in entirety) where what drove it. I don't like it; the use of the supplemental element is ugly, Yeah; well sorta: it’s specifically goobering up the document with duplicate data in the necessary `ref` attributes that annoys me. But I can’t think of any prettier approach that satisfies all design goals as per David’s argument. Where that gets nasty, of course, is when the href is relative and xml:base is being used to set the Base URI. Augh. Nasty indeed. However, it doesn’t concern me much, because in Atom, `atom:link` has no children and only a single URI-carrying attribution. Extensions will probably avoid adding namespaced attributes or elements to it (cf. current discussion). This means there’s little reason to apply an `xml:base` to an individual `atom:link`. The updated spec would have an appendix that would explain that previous versions of the extension defined the attributes and that some implementations have been deployed that use the attributes. The spec will indicate that those attributes are deprecated in favor of the thr:count element but that feed consumers have the discretion of whether or not to support them. I feel uncomfortable about it being codified for “eternity.” There are still Atom 0.2 feeds in the wild, even though they’re extremely rare. And we’re not seeing the end of Atom 0.3 anytime soon. With that experience in mind I’d really prefer that the previous approach not be legitimised even slightly, because that’s likely to lead consumer developers to feel that they need to support the old approach, and might lead publishers to probe that support. So I’d prefer that there be some pressure for the old approach to die quickly before it gets implemented in enough venues for the Atom 0.3 Effect to set in. I understand why you want it, though. -0.5, I suppose? I don’t know what to say about this. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread Draft Updated
On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote: Where that gets nasty, of course, is when the href is relative and xml:base is being used to set the Base URI. Publisher would need to make sure that the href/ref combo match up properly Would this be considered a match? link rel=replies href=comments xml:base=/06/04/21/blah/ / thr:count ref=/06/04/21/blah/comments updated=...5/thr:count You just know there'll be a few idiots that will try that on. e.
Re: Feed Thread Draft Updated
The feedvalidator really does need a ValidButPositivelyIdiotic warning. - James Eric Scheid wrote: On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote: Where that gets nasty, of course, is when the href is relative and xml:base is being used to set the Base URI. Publisher would need to make sure that the href/ref combo match up properly Would this be considered a match? link rel=replies href=comments xml:base=/06/04/21/blah/ / thr:count ref=/06/04/21/blah/comments updated=...5/thr:count You just know there'll be a few idiots that will try that on. e.
Re: Feed Thread Draft Updated
James M Snell wrote: a. Status quo. Leave things the way they are in the current draft +1 b. Drop thr:count and thr:when from the spec. +0.5 c. Create a new replies extension element -1 d. Create a supplemental extension element +0
Re: Feed Thread Draft Updated
A. Pagaltzis wrote: [snip] Maybe we can think of other ways to expose this information so that it fits the Atom extension model? Are those attributes really the only possible approach to this issue? Regards, Maybe, but given that WG messed up in not making the link element formally extensible, it's not likely to be pretty. Also, keep in mind that the uglier and more complicated the correct approach looks, the more implementors are going to gravitate towards less-than-correct approaches that meet their immediate needs. So, with that, let's catalog the options. a. Status quo. Leave things the way they are in the current draft with a firm warning to implementors that not all atom impls will be capable of supporting them. b. Drop thr:count and thr:when from the spec. c. Create a new replies extension element thr:replies href=... type=... hreflang=... title=... count=... when=... / d. Create a supplemental extension element d1: link rel=replies href=... / thr:replies ref=... count=... when=... / Where the ref attribute in thr:replies / is a unique identifier that can be matched to the resource linked by the replies link. If only a single replies link is specified, ref can be omitted. There could be one thr:replies for each replies link. d2: link rel=replies href=... / thr:replies count=... when=... / only one thr:replies would be specified regardless of the number of replies links. count would be reflective of the total number of known replies across all links. Of the options above, I'm fine with (a) and (b) ...in that order IMHO (c) is not a viable option, (d1) is ugly as hell and (d2) sacrifices the use case for a cleaner implementation. Please suggest additional options and/or arguments in-favor/against the options above. - James
Re: Feed Thread Draft Updated
On 13/4/06 8:02 AM, David Powell [EMAIL PROTECTED] wrote: In terms of the considerations to the interoperability of running code, thr:replies seems to beat atom:link in every way. It even manages to be more concise (you don't need the @rel), and you wouldn't need to put thr:count and thr:when into a namespace (namespaced attributes confuse people). atom:link beats thr:replies on the basis that I don't need to understand what replies are to discover that there is a link from this thing to that thing. atom processors know what atom:link is, but it wouldn't know what to do with this: xyz:qwerty foo=opaque-string bar=opaque-string qaz=opaque-string zak=opaque-string / e.
Re: Feed Thread Draft Updated
Thursday, April 13, 2006, 6:11:32 AM, Eric Scheid wrote: atom:link beats thr:replies on the basis that I don't need to understand what replies are to discover that there is a link from this thing to that thing. atom processors know what atom:link is, but it wouldn't know what to do with this: xyz:qwerty foo=opaque-string bar=opaque-string qaz=opaque-string zak=opaque-string / But what would processors do with an atom:link? Atom Protocol uses edit, there have been calls for a stylesheet. Links aren't necessarily things that you'd display to users (check HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL) -- Dave
Re: Feed Thread Draft Updated
David Powell wrote: But what would processors do with an atom:link? Atom Protocol uses edit, there have been calls for a stylesheet. Links aren't necessarily things that you'd display to users (check HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL) Well if you've got a decent feed API (hint: not the Microsoft one) you could ask it for a list of links on an entry without it having to know what all the link types are, and without you having to parse the XML yourself. If it was a really nice API it might even provide you with a set of extension attributes included with each link. Regards James
Re: Feed Thread Draft Updated
Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote: c. Create a new replies extension element thr:replies href=... type=... hreflang=... title=... count=... when=... / -0.5, it *is* a link thr:in-reply-to is a link too. An extension element was used for thr:in-reply-to, because atom:link wasn't up to the job. atom:link isn't up to the job for replies either. I think that slavishly adhering to convention, at the cost of interoperability is unwise. I'm bothered about this because I think requiring people to process undefined foreign markup is harmful to Atom. With something like an XHTML document, the only sensible way to process it is by using XML tools. XPath, XSLT, whatever - they work well. With Atom, an Atom Feed Document alone isn't very useful. Almost all applications will work in terms of Atom Feeds - streams of entries, and feed metadata. To process this, you need to think of Atom in terms of entities: Feeds and Entries, not a set of XML Feed documents. Implementations are based on OO classes and databases, and model entries in terms of titles, content, links, extensions etc. The Atom RFC is clear enough, that you can model an Atom Feed in terms of OO classes, rather than XML documents without losing any data. This all falls apart when people sprinkle the XML with undefined markup that can't be represented outside the context of an XML document. -- Dave
RE: Feed Thread Draft Updated
See below... http://www.kirit.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:owner-atom- [EMAIL PROTECTED] On Behalf Of David Powell Sent: Thursday, April 13, 2006 4:49 PM To: Thomas Broyer Cc: Atom-Syntax Subject: Re: Feed Thread Draft Updated I'm bothered about this because I think requiring people to process undefined foreign markup is harmful to Atom. With something like an XHTML document, the only sensible way to process it is by using XML tools. XPath, XSLT, whatever - they work well. With Atom, an Atom Feed Document alone isn't very useful. Almost all applications will work in terms of Atom Feeds - streams of entries, and feed metadata. To process this, you need to think of Atom in terms of entities: Feeds and Entries, not a set of XML Feed documents. Implementations are based on OO classes and databases, and model entries in terms of titles, content, links, extensions etc. The Atom RFC is clear enough, that you can model an Atom Feed in terms of OO classes, rather than XML documents without losing any data. This all falls apart when people sprinkle the XML with undefined markup that can't be represented outside the context of an XML document. This depends on what sort of application you're building though. As a content publisher it doesn't really make that much difference as I will choose the markup that I feels best represents my internal data and models (and which I think will be best understood and most relevant to my audience). If I am writing a desktop display tool then I'll work out which extensions are going to be of most use to somebody reading the contents of the feed. I'll probably ignore all sorts of things that are not relevant or I don't understand. My OO model is going to reflect what I'm going to draw on screen and so long as I can map incoming feeds to show them it's fine. The problem comes where I'm writing something that's going to repackage feeds. If I make the decision to preserve as much of the original markup then I have to allow for that in my internal models. I may however take the view that the audience that I'm repackaging the feeds for want me to transform it and that's part of my service. If I as a publisher have chosen to use some weird markup that maybe I've invented then that's my lookout. I should really make sure though that the feed is understandable at least on a basic level with just core Atom markup. If I can't do that then Atom may not be the best medium for me to publish in. K
Re: Feed Thread Draft Updated
On 13/4/06 6:59 PM, David Powell [EMAIL PROTECTED] wrote: But what would processors do with an atom:link? Atom Protocol uses edit, there have been calls for a stylesheet. Links aren't necessarily things that you'd display to users (check HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL) as I understand it, dereferencing the 'edit' link returns a representation of the entry which is suitable for editing (ie. it contains all the bits needed). as to the other link types in html ... I hope we've learned something from that experience since then. e.
Re: Feed Thread Draft Updated
* David Powell [EMAIL PROTECTED] [2006-04-13 11:10]: But what would processors do with an atom:link? Atom Protocol uses edit, there have been calls for a stylesheet. Links aren't necessarily things that you'd display to users (check HTML out for examples of that: favicon, P3P, Atom/RSS, GRDDL) Isn’t that what the `type` attribute is for? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread Draft Updated
Tuesday, April 11, 2006, 9:20:32 PM, James M Snell wrote: I also added a new warning for implementors: Implementors should note that while the Atom Syndication Format does not forbid the inclusion of namespaced extension attributes on the Atom link element, neither does is explicitly allow for such extensions. The result of this is that the thr:count and thr:when attributes fall outside of the guidelines for Atom extensions as defined in Section 6 of [RFC4287] and may not be supported by all Atom implementations. [Apologies to everyone for flogging this dead horse some more. I'm only doing this, because I care.] I'll quote your argument from MDP's blog and comment here, rather than on his dead comment thread, if that's ok: Ironically, the primary reason for using link for replies is because it makes very little sense to duplicate the function of the link element. I considered a thr:replies element. Ultimately, it would have looked and acted darn near identical to the atom:link element (with attributes like type, href, hreflang, etc). One needs to consider whether or not it makes sense to introduce a new namespaced extension element that duplicates the basic function of atom:link just to support the addition of two *optional* and *purely advisory* attributes. You recognize the fact that adding non-standard attributes on atom:link isn't going to be fully interoperable (that the thr:count and thr:when attributes might not make it from producer to consumer intact), but still prefer to make replies a link element on the basis of style and convention. This seems to be the wrong priority to me. Replacing atom:link rel=replies with an otherwise identical thr:replies element would fix the interop problem, and wouldn't introduce any other problems that I can think of. The only reason to keep the current link element is because it somehow looks better, or saves copy/pasting the relevant bits of the atom:link spec into the draft. In terms of the considerations to the interoperability of running code, thr:replies seems to beat atom:link in every way. It even manages to be more concise (you don't need the @rel), and you wouldn't need to put thr:count and thr:when into a namespace (namespaced attributes confuse people). Eg: thr:replies type=application/atom+xml href=http://www.example.org/mycommentsfeed.xml; count=10 when=2006-02-20T00:00:00Z / instead of: link rel=replies type=application/atom+xml href=http://www.example.org/mycommentsfeed.xml; thr:count=10 thr:when=2006-02-20T00:00:00Z / I don't really buy the justification that the attributes don't matter, so it is ok if they get lost btw. If I was using an API that didn't give access to the count attributes, I'd probably be a bit miffed, I'm unlikely to say oh it doesn't matter cause they were only advisory, I'll just load the comments feed, parse the XML, etc, etc, instead. Yes, thr:count is derived, so it isn't essential, but this doesn't mean that it isn't useful. It is obviously useful, else it wouldn't be in the draft. -- Dave
Re: Feed Thread Draft Updated
* David Powell [EMAIL PROTECTED] [2006-04-13 00:15]: This seems to be the wrong priority to me. Convincing arguments, IMHO; +1. James: As regards Robert’s vociferous comments, you have to acknowledge that while the rest of the draft was hashed out in several iterations, these `thr:count` and `thr:when` things snuck in at a late stage without any discussion. And, as regards David’s stance, I think it warrants a reminder that `thr:in-reply-to` started life as as an `in-reply-to` link relation as well, but we moved away from that because all of our attempts to twist Atom links into carrying all the additional semantics we needed ended up looking funny. So I would argue that the same appears to be a good idea for the `replies` relation since it grew beyond the scope of Atom links. I would even argue that what we are seeing here are really the first observed instances of a general best practice pattern for Atom extensions: Trying to extend `atom:link` is bad. If you need more semantics than afforded to it by RFC 4287, you should clone it and tweak the copy. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread Draft Updated
Hey Folks,Great discussion going on here... Thanks! http://www.oreillynet.com/xml/blog/2006/04/the_power_of_the_people.html On 4/12/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * David Powell [EMAIL PROTECTED] [2006-04-13 00:15]: This seems to be the wrong priority to me.Convincing arguments, IMHO; +1.James: As regards Robert's vociferous comments, you have to acknowledgethat while the rest of the draft was hashed out in severaliterations, these `thr:count` and `thr:when` things snuck in at alate stage without any discussion. And, as regards David's stance, I think it warrants a reminderthat `thr:in-reply-to` started life as as an `in-reply-to` linkrelation as well, but we moved away from that because all of ourattempts to twist Atom links into carrying all the additional semantics we needed ended up looking funny.So I would argue that the same appears to be a good idea for the`replies` relation since it grew beyond the scope of Atom links.I would even argue that what we are seeing here are really the first observed instances of a general best practice pattern forAtom extensions:Trying to extend `atom:link` is bad. If you need moresemantics than afforded to it by RFC 4287, you should clone it and tweak the copy.Regards,--Aristotle Pagaltzis // http://plasmasturm.org/-- M:D/ M. David Petersonhttp://www.xsltblog.com/
Re: Feed Thread Draft Updated
A. Pagaltzis wrote: * David Powell [EMAIL PROTECTED] [2006-04-13 00:15]: This seems to be the wrong priority to me. Convincing arguments, IMHO; +1. Sorry, not convinced. I never once claimed that the motivation for using link was because it looked better. What I did claim was that there is little to no technical justification for exactly duplicating the link element for the sole purpose of introducing two new optional attributes especially when the Atom spec expressly *allows* for such extensions. [snip] And, as regards David’s stance, I think it warrants a reminder that `thr:in-reply-to` started life as as an `in-reply-to` link relation as well, but we moved away from that because all of our attempts to twist Atom links into carrying all the additional semantics we needed ended up looking funny. So I would argue that the same appears to be a good idea for the `replies` relation since it grew beyond the scope of Atom links. With in-reply-to, the key issue that swung the argument in favor of a new extension element was whether or not the [EMAIL PROTECTED] attribute value could be an atom:id value or whether it had to be a dereferenceable URI. In other words, it was quite likely that ignorant implementations would do the Wrong Thing with a [EMAIL PROTECTED]in-reply-to]. Big difference in this case. There are no additional semantics that make the replies link look funny. It *looks* like a link; smells like a link; acts like a link; it *is* a link. The fact that that link MIGHT have two additional pieces of metadata associated with it does not make it any less of a link. Further, there is likely zero chance that properly coded rfc4287 implementations will do the Wrong Thing with a [EMAIL PROTECTED]replies], even if those implementations do choose to ignore-and-discard unknown foreign markup that happens to appear in the link. I would even argue that what we are seeing here are really the first observed instances of a general best practice pattern for Atom extensions: Trying to extend `atom:link` is bad. If you need more semantics than afforded to it by RFC 4287, you should clone it and tweak the copy. Not to be snarky, but that philosophy hasn't exactly worked out too well in the past (e.g. the rss 2.0 description tag). The Atom link element is well defined and does *everything* the replies link requires, right on down to the undefinedAttribute* and the definition of unknown foreign markup. Bottom line: I'd be far more inclined to either drop thr:when and thr:count from the spec or document a clear caveat that the two attributes are likely not to be supported in some implementations than I would be to use anything other than link for replies. - James
Re: Feed Thread Draft Updated
* James M Snell [EMAIL PROTECTED] [2006-04-13 04:10]: What I did claim was that there is little to no technical justification for exactly duplicating the link element for the sole purpose of introducing two new optional attributes... David countered that having this information is clearly useful, else these attributes would not be in the spec, which means there is a case to be made for making sure they’re available to all clients, even those behind an API that only provides access to Sec.6 extensions. With in-reply-to, the key issue that swung the argument in favor of a new extension element was whether or not the [EMAIL PROTECTED] attribute value could be an atom:id value or whether it had to be a dereferenceable URI. In other words, it was quite likely that ignorant implementations would do the Wrong Thing with a [EMAIL PROTECTED]in-reply-to]. My memory was different, so I went and re-read the threads. The non-dereferencable URI issue was an important sideline, but it was only a sideline in that discussion. If we were having that discussion now, I agree that it would be a much bigger sticking point, but back then, it was an also-ran. The big debate which swayed the issue at the time was having a mechanism for associating a source link with an in-reply-to link. We were trying all sorts of funny combinations with things nested inside the links or the links nested inside other things, IDREF attributes, and what have you. In the end, I put a big torch to my own proposition of an `in-reply-to` link relation to end the madness: http://www.imc.org/atom-syntax/mail-archive/msg16594.html Big difference in this case. There are no additional semantics that make the replies link look funny. It’s not nearly as funny-looking as that crazy in-reply-to business we came up with back then, conceded. Not to be snarky, but that philosophy hasn't exactly worked out too well in the past (e.g. the rss 2.0 description tag). But `description` can only appear once in an item, and therefore there has to be some precedence matrix between it and its derivatives. Not so with `atom:link` and clones, all of which may appear any number of times in an entry, and thus pose no precedence problem. In other words, comparing the two situations is not quite fair. Bottom line: I'd be far more inclined to either drop thr:when and thr:count from the spec or document a clear caveat that the two attributes are likely not to be supported in some implementations than I would be to use anything other than link for replies. Maybe we can think of other ways to expose this information so that it fits the Atom extension model? Are those attributes really the only possible approach to this issue? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread Draft Updated
James M Snell wrote: The Feed Thread draft has been updated. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-07.txt I am an absolutely terrible proofreader so I'd really appreciate it if someone could do a quick scan over the current doc to find the typos that I know must be scattered throughout. Section 4, paragraph 1: into a separate feed document (singular document) its value is assumed (no apostrophe) Section 4, last paragraph: neither does it explicitly allow (is - it) Section 6: Security considerations: (see section 5) (6 - 5) Not a proofreading issue, but shouldn't section 5 say something about DOS attacks using replies links to third party servers? I wouldn't be surprised if some clients automatically subscribed to all replies links in a feed even if they were 100MB zip files on a completely different site. Regards James
Re: Feed Thread Draft Updated
James Holderness wrote: [snip] Section 4, paragraph 1: into a separate feed document (singular document) its value is assumed (no apostrophe) Section 4, last paragraph: neither does it explicitly allow (is - it) Section 6: Security considerations: (see section 5) (6 - 5) Fixed in the next draft. Thank you. Not a proofreading issue, but shouldn't section 5 say something about DOS attacks using replies links to third party servers? I wouldn't be surprised if some clients automatically subscribed to all replies links in a feed even if they were 100MB zip files on a completely different site. Hmm.. this problem would apply generally to all types of Atom link wouldn't it? In any case, it likely would be good to at least mention that implementations should take care when using the replies link to automatically subscribe to feeds. - James
Re: Feed Thread Draft Updated
James M Snell wrote: Not a proofreading issue, but shouldn't section 5 say something about DOS attacks using replies links to third party servers? I wouldn't be surprised if some clients automatically subscribed to all replies links in a feed even if they were 100MB zip files on a completely different site. Hmm.. this problem would apply generally to all types of Atom link wouldn't it? In any case, it likely would be good to at least mention that implementations should take care when using the replies link to automatically subscribe to feeds. I don't think it necessarily applies to all links, just those that are likely to be followed automatically. I'm fairly sure I've seen aggregators that have an option for automatically subscribing to wfw:commentRss links so I'm assuming they're likely to do the same for this extension. Enclosures are another link type where I would consider this an issue. I didn't see anything mentioned in the security section of RFC4287 though, so maybe it's not such a big deal. Mark's feed history draft covers it, but it could be argued that the feed history links probably SHOULD be followed, whereas enclosure and replies links only MAY be followed. Anyway I'm not really sure it's essential. I just thought I should mention it in case it's the kind of thing that causes problems for you when submitting to the IETF. Regards James
Re: Feed Thread Draft
On 26/1/06 4:23 PM, James M Snell [EMAIL PROTECTED] wrote: thr:in-reply-to id=tag:example.org,2006:/some/entry is that id for the thing being replied to, or the id of this thr:in-reply-to element? if the former, is suspect idref would be more appropriate. but what do I know? e.
Re: Feed thread draft
A. Pagaltzis wrote: Given this constraint, do you have a better idea how do address the following concerns? • Threading-unaware clients should get at least some information that allows the user to notice that there’s more to the entry, even if the user agent remains blissfully unaware of the thread as such. I think a related link that points to the permalink of the original message is a good start. • The available information precise enough that threading-aware can correlate all the related bits without guessing. What about something like this: th:in-reply-to idtag:www.example.org:2005:entry1/id link rel=feed type=application/atom+xml href=http://www.example.org/feed.atom/ link rel=related type=text/html href=http:www.example.org/entry1.html/ /th:in-reply-to No doubt there are issues with the syntax, but the important concept is the idea of having two clearly defined links: one being the permalink for the entry being replied to and the other being the atom feed in which that entry can be found. It could be made more flexible by allowing further alternate links, but I'm not sure that's necessary. Honestly, I haven’t seen any yet that do anything interesting at all with extra links (be they related, via, or something else)… (Which rather irks me.) Me neither. I can't say I'm exactly doing anything interesting with links, but I am at least doing something with them. Regards James
Re: Feed thread draft
* James Holderness [EMAIL PROTECTED] [2005-12-13 03:55]: What about something like this: th:in-reply-to idtag:www.example.org:2005:entry1/id link rel=feed type=application/atom+xml href=http://www.example.org/feed.atom/ link rel=related type=text/html href=http:www.example.org/entry1.html/ /th:in-reply-to No doubt there are issues with the syntax, The biggest issue being that a threading-unaware client won’t know to go looking inside thr:in-reply-to to find links. This syntax will only satisfy the “allow threading-unaware clients to do something useful” constraint if you duplicate the links at the atom:entry level. but the important concept is the idea of having two clearly defined links: one being the permalink for the entry being replied to and the other being the atom feed in which that entry can be found. It could be made more flexible by allowing further alternate links, but I'm not sure that's necessary. If the extensibility afforded by child elements is not a useful goal (and in this case, I think it isn’t; is there more information that is going to be needed than the source feed and permalink?), that could be handled cleanly by just adding an @alternate attribute to thr:in-reply-to to record the permalink. atom:link elements can then simply be added to the atom:entry. This keeps things nicely flat and simple. I am not sure that the semantics of adding atom:[EMAIL PROTECTED]'feed'] to atom:entry are particularly clean; but we might just decide that it isn’t a great loss if threading-unaware clients miss the feed link. Or else we’d need to pick a better name for the relation. So the changes would be: • Rename @href to @source. • Repurpose @href to contain the alternate link. • Change the recommendation to include an atom:[EMAIL PROTECTED]'related'] to point to the alternate link instead of the feed. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed thread draft
* James Holderness [EMAIL PROTECTED] [2005-12-11 03:55]: What do you think such a client would typically do with related links? I don't know about anyone else, but what I do is display them in a see also list that the user can launch in a browser window. This works very well when the links are to web pages or other resources that can be handled usefully by a browser, but it's a complete waste of time if the link is pointing to an Atom feed. You do that even if it’s link rel=related type=application/atom+xml href=... / ? Maybe there's a better way. Can you imagine some other way in which clients might handle related links (without knowing anything about this extension) that would be able to do something useful with a link that pointed to an Atom feed - specifically the Atom feed that the current message is replying to? Minimally, it can pull the feed and look for its alternate link. Less minimally it can also look at all the other metadata that Atom documents can contain. We’re talking about an Atom consumer here; that it wouldn’t be able to do something sensible with Atom docs strikes me as an odd objection. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed thread draft
James M Snell wrote: What is the type of the resource pointed to by the in-reply-to href? It It's whatever type the server says it is when you GET it (Content-Type header). Well ideally you wouldn't want to GET or HEAD every href in order to determine its type. I'm not positive this is a problem, but it may be depending on what a client may want to do with this extension. The related link allows clients that are not familiar with the Feed Thread extension to at least be able to indicate that there is some kind of relationship between the two resources. Imagine that a client doesn't know anything about this extension. What do you think such a client would typically do with related links? I don't know about anyone else, but what I do is display them in a see also list that the user can launch in a browser window. This works very well when the links are to web pages or other resources that can be handled usefully by a browser, but it's a complete waste of time if the link is pointing to an Atom feed. Most of the time the user will just get a page of meaningless XML - at best they'll get the option to subscribe to a feed that they're quite likely already subscribed to. But that's just how I handle links. Maybe there's a better way. Can you imagine some other way in which clients might handle related links (without knowing anything about this extension) that would be able to do something useful with a link that pointed to an Atom feed - specifically the Atom feed that the current message is replying to? Now if the in-reply-to href was pointing to a web page I could understand recommending a related link that pointed there too. So maybe you could limit the recommendation like that. Or otherwise just leave out the recommendation altogether and let the feed producer decide whether a related link is a good idea or not. Related links are already part of the Atom spec - there's nothing stopping a feed producer using them - but I'm not sure they should be encouraged to do so with links which may not be at all appropriate. Regards James
Re: Feed thread draft
James Holderness wrote: James M Snell wrote: The feed thread draft is a major update that includes a simplification of the in-reply-to element. in-reply-to id=tag:example.org,2005:some-unique-id href=http://example.com/some-location; / I really like what you've done with this. I have a couple of questions though. What is the type of the resource pointed to by the in-reply-to href? It It's whatever type the server says it is when you GET it (Content-Type header). seems to me it can't be an Atom feed since that isn't really a representation of the resource being responded to (although that would probably be most useful here). An Atom entry document? An HTML web page? What would you expect a client application to do with this value? A link to the source feed I could see myself using (in combination with the id obviously), but I'm not sure about the other two. Most likely it will end up being the source feed. The idea was to leave this un(der)specified for now and let implementors figure out what works best. Second question: what is the reason for recommending a related link when the href points to something external? It seems to me an unnecessary duplication of information but I may be missing something. And once again what would you expect the client to do with it? A HTML page could be provided to the user as a clickable link, but an Atom feed? An Atom entry document? Obviously the answer to this depends on the type of the href, which brings us back to initial question. The related link allows clients that are not familiar with the Feed Thread extension to at least be able to indicate that there is some kind of relationship between the two resources. - James
