Re: Changing feed thread (was: Re: Atom Thread Feed syntax)
2006/3/24, James M Snell [EMAIL PROTECTED]: 1. Do I change in-reply-to id=... / to in-reply-to ref=... / ? +0.5, I have no real problem with id but as it seems to bother some people… and.. to address David's concerns about extending atom:link... 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? +1 None of the implementors I'm aware of are currently making use of multiple replies link relations on an entry so changing #2 likely wouldn't cause too many headaches. I wouldn't understand what really does mean the following: link rel=replies href=comments.html type=text/html thr:count=5 / link rel=replies href=comments.atom type=application/atom+xml thr:count=10 / Without the thr:count, I'd say that those two links are intended for client-side content negotiation, but given that the two thr:count values differ… would it mean that there have been 5 new comments since the text/html representation has been last updated? But what if there were a thr:when indicating the opposite? And Rob Sayre also pointed on his blog a potential problem on how to use such multiple values: How do I display that in a client? Do I add up the numbers? Pick the highest? Do I pick the latest or the earliest time?. [http://www.franklinmint.fm/blog/archives/000721.html] I know what your answer is [http://www.snellspace.com/wp/?p=297] but I also think that these are entry properties, not really link properties (so I disagree with you on First, The thr:count and thr:when properties are specific to the replies link upon which they appear. [http://www.snellspace.com/wp/?p=296]). -- Thomas Broyer
Re: Changing feed thread (was: Re: Atom Thread Feed syntax)
* James M Snell [EMAIL PROTECTED] [2006-03-24 21:30]: 1. Do I change in-reply-to id=... / to in-reply-to ref=... / ? +1, in case my implicit vote isn’t already counted. 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? +0; but I don’t plan on using those on either end of the wire. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Atom Thread Feed syntax
Just wanted to follow through on this for everyone. Given that there are vendors getting ready to ship code based on the current rev of the spec, I'm *not* going to rename the id attribute to ref. Yes, I know that id is confusing to some folks, but we're just talking the name of a single attribute and not a critical functional bug. From this point forward, only critical spec bugs will be fixed and I will be submitting the spec for consideration as a standards track RFC in the not too distant future. - James First of all thanks for the follow-up, this is appreciated. Now I do understand your motivation at keeping the name of the attribute and I also believe people that will be reading such feed won't make the mistake. Fir enough. It's not that a big deal... or is it? I do find a bit hard to swallow though the implemantators do it that way so let's not update the RFC which is still a draft, even if an advanced one. I simply wonder what is worse, to annoy a few vendors now or a wider audience in the future. Anyway, so be it. I won't argue and I leave you the final word on this one ;) - Sylvain
Re: Atom Thread Feed syntax
Friday, March 24, 2006, 3:28:02 AM, James Snell wrote: I believe the concern is over the thr:count and thr:when attributes for the replies link relation, both of which are optional, and both of which provide what I consider to be extra information. In other words, it's ok if an implementation drops them. Yeah I agree that an implementation losing those attributes wasn't exactly life-threatening. But is it *ok* if an implementation drops them? Will publishers think that it is ok if some infrastructure drop those attributes? Will subscribers? Presumably publishers have spent some effort adding those attributes to the feed, in the hope that subscribers will get some benefit from them. The important bit is the in-reply-to element and the replies link rel, both of which fall within the bounds of the Atom extension model. Yeah, I agree. I'm most certainly not abandoning the extension constructs. One of the motivations for walking these extension specs through the I-D and eventually standards-track process is so that they get their own RFC number. Implementations that choose to support the extension can point to RFC4287 *and* RFCwhatever and say, I support both. If an implementation only says I support RFC4287 and doesn't say anything about RFCwhatever, it's pretty clear what the result would be. The most an RFC4287 implementation should be expected to do is adhere to the defined extension model. If that implementation also chooses to support other RFC's that go beyond that extension model, so be it. I find much of section 6 of RFC4287 a bit pointless. It describes these classes of extensions, and I just think - so what?. I think it would be good to have a second draft which described a number of conformance levels for feed infrastructure - things like the handling, and preservation or not, of extensions. Then publishers would know that if a popular infrastructure (Windows RSS, Rome, Feedburner, APP implementations, etc) implements a given level of a compliance, what to expect. It isn't always preferable for a feed to reappear exactly as it was after travelling through an API or APP store, much of the added value in implementations will come from the transformations that they do. Even producing an archive feed, isn't possible without a reasonable number of transformations (eg: storing inherited constructs: author, base, lang, rights with the entry). That said, the critical parts of the Feed Thread draft (the in-reply-to element and the replies link rel) follow the guidelines of the Atom extension model. That is, any RFC4287 implementation *should* be able to do something with those elements (even if it's just preserving them). The optional parts of the extension (thr:count an thr:when) fall outside of the Atom extension model. That's ok. Implementations can choose to ignore those things, even completely drop them. My hope is that implementors will be able to think of Atom in terms of Entries, Feeds, and everything else; rather than in terms of XML, a fragile document markup language. As for the other extension drafts I put out, keep in mind that most should be considered strictly experimental at this time. That said, there is really only one that really falls outside the extension model.. the Link Extensions draft [1]... which, by definition cannot adhere to the extension model given the fact that Atom link elements are actually not extensible. I haven't looked at them all thoroughly. Do you want to extend link elements rather than use extension elements in these cases because you expect that link constructs are more likely to provide a UI in implementations? I suppose that there are workarounds, eg: feed ex:linkinfo href=http://www.example.org/mycommentsfeed.xml; ex:count10/ex:count ex:when2006-02-20T00:00:00Z/ex:when /ex:linkinfo entry link rel=replies type=application/atom+xml href=http://www.example.org/mycommentsfeed.xml; / /entry /feed -- Dave
Re: Atom Thread Feed syntax
David Powell wrote: Friday, March 24, 2006, 3:28:02 AM, James Snell wrote: I believe the concern is over the thr:count and thr:when attributes for the replies link relation, both of which are optional, and both of which provide what I consider to be extra information. In other words, it's ok if an implementation drops them. Yeah I agree that an implementation losing those attributes wasn't exactly life-threatening. But is it *ok* if an implementation drops them? Will publishers think that it is ok if some infrastructure drop those attributes? Will subscribers? Presumably publishers have spent some effort adding those attributes to the feed, in the hope that subscribers will get some benefit from them. Yes, I think it's ok to drop them. In fact, I'll likely add something to the spec that discusses this issue.. specifically, that the thr:count and thr:when attributes fall outside of the atom extensibility model and may not be preserved by strictly compliant RFC4287 implementations. In other words, here they are, but use at your own risk. [snip] The most an RFC4287 implementation should be expected to do is adhere to the defined extension model. If that implementation also chooses to support other RFC's that go beyond that extension model, so be it. I find much of section 6 of RFC4287 a bit pointless. It describes these classes of extensions, and I just think - so what?. I agree, but... I think it would be good to have a second draft which described a number of conformance levels for feed infrastructure - things like the handling, and preservation or not, of extensions. Then publishers would know that if a popular infrastructure (Windows RSS, Rome, Feedburner, APP implementations, etc) implements a given level of a compliance, what to expect. It isn't always preferable for a feed to reappear exactly as it was after travelling through an API or APP store, much of the added value in implementations will come from the transformations that they do. Even producing an archive feed, isn't possible without a reasonable number of transformations (eg: storing inherited constructs: author, base, lang, rights with the entry). In my view of the current spec, Atom has two layers of extensibility. One layer is defined in section 6. The other is defined by XML. A strictly compliant RFC4287 implementation should only be expected to comply with section 6, but that doesn't mean the implementation cannot also support general extensibility on the XML layer. [snip] My hope is that implementors will be able to think of Atom in terms of Entries, Feeds, and everything else; rather than in terms of XML, a fragile document markup language. Yep. In the Atom implementation I've written, the entire XML infoset is preserved with an Atom object model layered over the top. E.g. code can work with Feed, Entry, Link, etc. As far as extensibility is concerned, that Atom object model only exposes section 6 extensions. If the app developer wants to look at things from an XML perspective, they can peel back a layer and work with the infoset directly. I haven't looked at them all thoroughly. Do you want to extend link elements rather than use extension elements in these cases because you expect that link constructs are more likely to provide a UI in implementations? I want to extend Link because there is little sense in reinventing it. It would be silly for me to have a foo:link / sitting side by side with atom:link / when both serve the same general purpose. It was a mistake not to make atom:link extensible per section 6. However, this is still XML and Atom allows undefined content and undefined attributes on atom:link, so, I'm free to do what I want with atom:link so long as I'm aware up front that what I'm doing falls outside the bounds of Atom's section 6 extensibility model. Personally, I think that folks will find in the long run that section 6 really is pointless. I suppose that there are workarounds, eg: feed ex:linkinfo href=http://www.example.org/mycommentsfeed.xml; ex:count10/ex:count ex:when2006-02-20T00:00:00Z/ex:when /ex:linkinfo entry link rel=replies type=application/atom+xml href=http://www.example.org/mycommentsfeed.xml; / /entry /feed Blech. :-) - James
Re: Atom Thread Feed syntax
For me it's a matter of the fact that the spec has gone through 6 revisions and two design overhauls since it was first pitched. It's been out there for quite a while. At some point, the design discussions need to end and it needs to stablize so that folks can do something real with it. If, during that process, some folks get annoyed, so be it, that's the nature of the game. No spec is perfect, nor should we waste our time trying to make them so. Is the spec good enough? I think so. Are there any functional bugs? I don't think so. Can the spec text be improved? Definitely, and I'll likely do so one more time between now and when it's actually submitted for consideration as a standards track RFC. - James Sylvain Hellegouarch wrote: [snip] I do find a bit hard to swallow though the implemantators do it that way so let's not update the RFC which is still a draft, even if an advanced one. I simply wonder what is worse, to annoy a few vendors now or a wider audience in the future. Anyway, so be it. I won't argue and I leave you the final word on this one ;) - Sylvain
Changing feed thread (was: Re: Atom Thread Feed syntax)
Sylvain Hellegouarch wrote: Hi James, For me it's a matter of the fact that the spec has gone through 6 revisions and two design overhauls since it was first pitched. It's been out there for quite a while. At some point, the design discussions need to end and it needs to stablize so that folks can do something real with it. If, during that process, some folks get annoyed, so be it, that's the nature of the game. Well I find you a bit aggressive here I haven't said I was annoyed nor anybody else. I'm sorry for not being there during the first months you've put that draft in shape. There is no place I have seen where you said in the first place the discussions were over until now by the way. Not a problem :-) I had announced an informal last-call back around the December 2005 timeframe. But that was more or less designed to get folks to actually read the spec than it was to lock things down. The discussions are definitely not over but I want to avoid making generally cosmetic changes because there are always going to be some folks who aren't going to be happy. No spec is perfect, nor should we waste our time trying to make them so. Is the spec good enough? I think so. You do but recognise at least that what was merely a question from my part showed that a few people hanging around here agreed on the misleading name and a good alternative was quickly found. You have the right to dismiss of course. I also agree that the name change would be good and I seriously considered making the change. If I hear from enough implementors that say changing it would not be a problem, I'd likely go ahead and do so. (e.g. when I say final I usually mean more than likely final but I'm always open to be convinced otherwise ;-) ..) Are there any functional bugs? I don't think so. Can the spec text be improved? Definitely, and I'll likely do so one more time between now and when it's actually submitted for consideration as a standards track RFC. Well I wonder how since you define what's important and what's not. Please don't misinterpret, I'm not disregarding any point of view on this. I've seriously considered every bit of feedback offered and greatly appreciate it.. and, like I said above, it's always possible to convince me to make a change if there's enough support for it. So, with that, let me go ahead and open it up to a vote with the caveat that votes from folks with concrete plans to implement the spec will carry more weight so I'd appreciate a heads up. 1. Do I change in-reply-to id=... / to in-reply-to ref=... / ? and.. to address David's concerns about extending atom:link... 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? None of the implementors I'm aware of are currently making use of multiple replies link relations on an entry so changing #2 likely wouldn't cause too many headaches. My apologies if I came across a little too heavy handed on this. That was most definitely *not* the intention. - James
Re: Changing feed thread (was: Re: Atom Thread Feed syntax)
James M Snell wrote: 1. Do I change in-reply-to id=... / to in-reply-to ref=... / ? I don't know enough to care what you call those attributes. And it's a long way before we'll go live with anything so if you need to change attribute names it wouldn't bother me in the least. 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? I currently have no interest in supporting either of those so it doesn't matter to me. Regards James
Re: Atom Thread Feed syntax
Just wanted to follow through on this for everyone. Given that there are vendors getting ready to ship code based on the current rev of the spec, I'm *not* going to rename the id attribute to ref. Yes, I know that id is confusing to some folks, but we're just talking the name of a single attribute and not a critical functional bug. From this point forward, only critical spec bugs will be fixed and I will be submitting the spec for consideration as a standards track RFC in the not too distant future. - James Sylvain Hellegouarch wrote: Hi everyone, I was reading the Atom Feed Thread draft [1] yesterday and I ran into a problem as I described in my blog [2]. To recap the 'in-reply-to' element defined in that specification takes an 'id' attribute that specifies /the universally unique identifier of the resource being responded to/. Calling such an attribute 'id' is a mistake in my opinion as it confuses with the actual ID of the element itself within the XML document it belongs to and it makes impossible for another element within the document to have the same value as an 'id'. I would rather move the content of that attribute as a text element of the 'in-reply-to' element (as does the atom:id element). Thoughts? - Sylvain [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-05.txt [2] http://www.defuze.org/archives/2006/03/14/about-atom-feed-threads
Re: Atom Thread Feed syntax
Thursday, March 23, 2006, 9:39:09 PM, James M Snell wrote: Just wanted to follow through on this for everyone. Given that there are vendors getting ready to ship code based on the current rev of the spec, I'm *not* going to rename the id attribute to ref. Yes, I know that id is confusing to some folks, but we're just talking the name of a single attribute and not a critical functional bug. From this point forward, only critical spec bugs will be fixed and I will be submitting the spec for consideration as a standards track RFC in the not too distant future. I'm more bothered about the use of undefined markup on the link element. I know, I know, I keep going on and on about this, but I keep seeing more drafts that do the same thing and it isn't just a theoretical problem: Windows Feed Platform does not preserve arbitrary markup other than proper extension elements. Other feed stores and servers are likely to do the same (justifiably IMO). The abandonment of extension constructs in favour of undefined markup by this draft, and other draft-*-atompub-* drafts would be an interoperability concern if these drafts were deployed. If you want to extend Atom, use Extension Elements. -- Dave
Re: Atom Thread Feed syntax
* David Powell [EMAIL PROTECTED] [2006-03-24 02:20]: The abandonment of extension constructs in favour of undefined markup by this draft, and other draft-*-atompub-* drafts would be an interoperability concern if these drafts were deployed. If you want to extend Atom, use Extension Elements. I don’t follow. Please explain how these drafts fail to satisfy the criteria in Section 6.4.2, Structured Extension Elements. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Atom Thread Feed syntax
I believe the concern is over the thr:count and thr:when attributes for the replies link relation, both of which are optional, and both of which provide what I consider to be extra information. In other words, it's ok if an implementation drops them. The important bit is the in-reply-to element and the replies link rel, both of which fall within the bounds of the Atom extension model. - James A. Pagaltzis wrote: * David Powell [EMAIL PROTECTED] [2006-03-24 02:20]: The abandonment of extension constructs in favour of undefined markup by this draft, and other draft-*-atompub-* drafts would be an interoperability concern if these drafts were deployed. If you want to extend Atom, use Extension Elements. I don’t follow. Please explain how these drafts fail to satisfy the criteria in Section 6.4.2, Structured Extension Elements. Regards,
Re: Atom Thread Feed syntax
David Powell wrote: [snip] The abandonment of extension constructs in favour of undefined markup by this draft, and other draft-*-atompub-* drafts would be an interoperability concern if these drafts were deployed. If you want to extend Atom, use Extension Elements. I'm most certainly not abandoning the extension constructs. One of the motivations for walking these extension specs through the I-D and eventually standards-track process is so that they get their own RFC number. Implementations that choose to support the extension can point to RFC4287 *and* RFCwhatever and say, I support both. If an implementation only says I support RFC4287 and doesn't say anything about RFCwhatever, it's pretty clear what the result would be. The most an RFC4287 implementation should be expected to do is adhere to the defined extension model. If that implementation also chooses to support other RFC's that go beyond that extension model, so be it. That said, the critical parts of the Feed Thread draft (the in-reply-to element and the replies link rel) follow the guidelines of the Atom extension model. That is, any RFC4287 implementation *should* be able to do something with those elements (even if it's just preserving them). The optional parts of the extension (thr:count an thr:when) fall outside of the Atom extension model. That's ok. Implementations can choose to ignore those things, even completely drop them. As for the other extension drafts I put out, keep in mind that most should be considered strictly experimental at this time. That said, there is really only one that really falls outside the extension model.. the Link Extensions draft [1]... which, by definition cannot adhere to the extension model given the fact that Atom link elements are actually not extensible. [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-02.txt - James
Re: Atom Thread Feed syntax
Thomas Broyer [EMAIL PROTECTED]: Sylvain Hellegouarch [EMAIL PROTECTED]: I would rather move the content of that attribute as a text element of the 'in-reply-to' element (as does the atom:id element). I raised a similar issue regarding James Snell's Feed Rank I-D where a ranking:scheme element has an @id attribute containing a IRI. In this case the attribute is not used as a reference to another element, though, but as an identifier of the ranking:scheme itself. (ranking:rank elements refer to ranking:schemes via a @scheme attribute, which contains the identifying IRI in question.) In this case I think the analogy with atom:entry or atom:feed is justified, so one conceivably could have something like the following: ranking:scheme ... ranking:idhttp://example.org/five-stars/ranking:scheme /ranking:scheme (In a mail James Snell proposed changing @id to @name, instead.) Eventually, I'd rather rename it to resource-id… Considering the above-mentioned symmetry with @href, I’m coming around to whose-ever view it was that this attribute should be called @ref for balance. But the issue raised by the OP is subtly different from the Feed Rank one, since the Feed Rank I-D uses @id to label a ranking:scheme, whereas the Feed Thread I-D uses @id to link to an atom:entry. In the latter case the analogy to atom:id is IMHO unjustified, since atom:id serves as a label, not a link. @ref, however, sounds like an entirely reasonable name for such an attribute. Just my 2 Zorkmids. Andreas Sewe
Re: Atom Thread Feed syntax
Considering the above-mentioned symmetry with @href, I’m coming around to whose-ever view it was that this attribute should be called @ref for balance. +1 for @ref as well.
Re: Atom Thread Feed syntax
Andreas Sewe wrote: @ref, however, sounds like an entirely reasonable name for such an attribute. I'm coming around to this view as well. On the downside, there are implementations of the draft that are being prepared now, I will ping the folks who I know are implementing and see if a name change for this attribute would cause any inconvenience. - James
Atom Thread Feed syntax
Hi everyone, I was reading the Atom Feed Thread draft [1] yesterday and I ran into a problem as I described in my blog [2]. To recap the 'in-reply-to' element defined in that specification takes an 'id' attribute that specifies /the universally unique identifier of the resource being responded to/. Calling such an attribute 'id' is a mistake in my opinion as it confuses with the actual ID of the element itself within the XML document it belongs to and it makes impossible for another element within the document to have the same value as an 'id'. I would rather move the content of that attribute as a text element of the 'in-reply-to' element (as does the atom:id element). Thoughts? - Sylvain [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-05.txt [2] http://www.defuze.org/archives/2006/03/14/about-atom-feed-threads
Re: Atom Thread Feed syntax
Hello Thomas, It could lead to confusion, but as Atom doesn't define such an attribute in its own namespace (or on elements in its own namespace) and as no other extension that I know of do that either, I don't think it really matters… You are right Atom does not define such an attribute but I'd be happier if extensions could follow Atom conventions as well. Atom sets the atom:id value not as in an attribute of atom:id but as its content. Why not following the convention in the first place? Besides the fact there is no other extension to do so as of yet is quite irrelevant to me. Atom extensions are fairly young and hopefully they'll be more and more spreaded. I'm sorry to have to tell you that you *are* mistaken… Having an attribute named id doesn't make it an ID (in the sense of a unique identifier throughout the document, such as the ID type in a DTD of xs:ID in XMLSchema), otherwise: - you wouldn't have to declare them explicitely in your DTDs and there wouldn't be a need for an ID (resp. xs:ID) type in DTD (resp. XMLSchema) - the validity constraint One ID Per Element Type [http://www.w3.org/TR/REC-xml/#one-id-per-el] could never be met as soon as you'd declare an ID attribute with a name different from id - there wouldn't have been a need for xml:id [http://www.w3.org/TR/xml-id/] Again this is a matter of convention in my opinion. When reading an XML document I don't want to be obliged to think about the actual meaning of an id attribute. You are indeed right (and thank you for explaining it to me) in terms of specification but conventions are often as important. Specially for people like me who are not XML guru. Thanks for your feedback by the way :) - Sylvain
Re: Atom Thread Feed syntax
2006/3/16, Sylvain Hellegouarch [EMAIL PROTECTED]: It could lead to confusion, but as Atom doesn't define such an attribute in its own namespace (or on elements in its own namespace) and as no other extension that I know of do that either, I don't think it really matters… You are right Atom does not define such an attribute but I'd be happier if extensions could follow Atom conventions as well. Atom sets the atom:id value not as in an attribute of atom:id but as its content. Why not following the convention in the first place? Because they don't deserve the same role. atom:id gives the identifier of the resource _described_ by the containing element, while thr:in-reply-to/@id gives the identifier of the resource _referenced_ by the containing element (or, actually, gives an identifier _as a reference_ to this resource). In that sense, thr:in-reply-to deserves the same role as @href. If you get back to previous versions of the threading extension, you'll see that it had been proposed that there would only be @href, whether or not the given IRI were to be dereferenced (e.g. by making an HTTP request) or just used as a globally unique identifier. This has been worked out because a) people (including me) wanted that these roles (retrieving vs. identifying) be clearly distinguished and b) there wouldn't then have a mean to give both the resource identifier and an IRI where to retrieve a copy of it. Having an attribute named id doesn't make it an ID (in the sense of a unique identifier throughout the document, such as the ID type in a DTD of xs:ID in XMLSchema), […] Again this is a matter of convention in my opinion. When reading an XML document I don't want to be obliged to think about the actual meaning of an id attribute. You are indeed right (and thank you for explaining it to me) in terms of specification but conventions are often as important. Specially for people like me who are not XML guru. Well, I wouldn't describe myself as an XML guru either ;-) -- Thomas Broyer
Re: Atom Thread Feed syntax
* Thomas Broyer [EMAIL PROTECTED] [2006-03-16 20:15]: 2006/3/16, Sylvain Hellegouarch [EMAIL PROTECTED]: Atom sets the atom:id value not as in an attribute of atom:id but as its content. Why not following the convention in the first place? Because they don't deserve the same role. atom:id gives the identifier of the resource _described_ by the containing element, while thr:in-reply-to/@id gives the identifier of the resource _referenced_ by the containing element (or, actually, gives an identifier _as a reference_ to this resource). In that sense, thr:in-reply-to deserves the same role as @href. +1 * Thomas Broyer [EMAIL PROTECTED] [2006-03-16 17:40]: 2006/3/16, Sylvain Hellegouarch [EMAIL PROTECTED]: I would rather move the content of that attribute as a text element of the 'in-reply-to' element (as does the atom:id element). Eventually, I'd rather rename it to resource-id… Considering the above-mentioned symmetry with @href, I’m coming around to whose-ever view it was that this attribute should be called @ref for balance. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
