Re: Feed Thread in Last Call
On May 23, 2006, at 12:16 PM, Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I find this to be a pretty compelling argument. Unless RFC4287 were rewritten (with a time machine, perhaps) to forbid extensions in attributes, extension writers will occasionally put data in attributes, and the libraries will have to deal with this, regardless of how the Thread proposal works. Lisa
Re: Feed Thread in Last Call
On 5/30/06, Lisa Dusseault [EMAIL PROTECTED] wrote: At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I find this to be a pretty compelling argument. I don't find Tim's argument particularly compelling. It's crystal ball stuff, and implementations are free to ignore *any* part of an Atom document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim and others want that to be true, they have an RFC to revise. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
Robert Sayre wrote: [snip] document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim The exact same can be said of the argument that the use of extension attributes is broken. There's not a shred of spec text to back it up. and others want that to be true, they have an RFC to revise. The spec is clear. Extension attributes are allowed by the spec. Implementations that do not support extension attributes are choosing not to support a feature allowed by the spec. Whether that makes those implementations broken or not is debatable. Personally, I don't see them as broken, I just see them as extremely short-sighted. - James
Re: Feed Thread in Last Call
On 5/30/06, James M Snell [EMAIL PROTECTED] wrote: Robert Sayre wrote: [snip] document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim The exact same can be said of the argument that the use of extension attributes is broken. There's not a shred of spec text to back it up. I didn't say the use of extension attributes is broken. I said your extension has no reason to use them, remember? You never gave a technical reason for the change between last call and the previous version. Personally, I don't see them as broken, I just see them as extremely short-sighted. That's how I see your extension. Hey, maybe you could do RFC4287bis as an individual submission! -- Robert Sayre
Re: Feed Thread in Last Call
Tuesday, May 23, 2006, 10:31:37 PM, Tim Bray wrote: I would say that furious debates about elements-vs-attributes have been going on since the dawn of XML in 1998, but that would be untrue; they've been going on since the dawn of XML's precursor SGML in 1986. They have never led anywhere. After you've noticed that if you need nested element structure you're stuck with elements, and if you don't want to have two things with the same names attributes can help, there really aren't any deterministic decision procedures. I note with pleasure that *all* known XML APIs allow you to retrieve elements and attributes with about the same degree of difficulty. What Aristotle said. Yes, I agree, but debate over elements vs attributes in generic XML isn't relevant. So, my conclusion: I disagree with Powell. Let people put extensions wherever they feel like putting them (they will anyhow), remembering that human-readability is a virtue. If models try to micro-manage the element/attribute thing, those models are broken, don't use them. If software arbitrarily discards markup because the markup doesn't match its idiosyncratic ideas about elements and attributes, that software is non-comformant and non-interoperable. I'm a bit surprised that you're saying this. I'm not sure why you think it is non-conformant to discard extensions. RFC4287 doesn't describe any conformance criteria for Atom intermediaries. Over on atom-protocol, there were a number of implementors who are ignoring/rewriting client-supplied atom:ids - about the most fundamental way that you could possibly change an atom document - and you didn't seem to disapprove of this? People have also said in the past that they planned not to preserve extensions, and I don't remember there being many objections. If it is non-conformant and non-interoperable to discard extensions, then why doesn't APP prohibit it? Extension elements are defined to have both a model and a syntax, but Atom's allowance for foreign attributes to appear anywhere is a case of syntax that has no corresponding model. Atom doesn't really explain what foreign attributes are intended for. Extension elements also, as noted above, have *no normative effect*. I don't know what no normative effect means. This is only true for software which ignores the fact that RFC4287 is specified only in terms of the XML Infoset. If you lose information because it doesn't match up with some ex post facto model you've dreamed up, you cannot expect to achieve interoperability. But every implementor is dreaming up ex post facto models. Obviously, but the notion that this depends on whether you use an attribute or an element seems really, really bizarre to me. An intermediary that drops markup it doesn't recognize won't last long in the marketplace, whether those are elements or attributes. It is easier to support extensibility in 3 places, than on every possible element in the document. Storing entry extensions in a database table is possible, storing atom:updated attributes, is getting silly. Interoperability should take priority of concerns that 'approach X looks better than Y', and other unjustifiable minor concerns. Yes, and interoperability is based on the normative rules in RFC4287, right? Wrong (in my opinion). There are no normative rules for the behaviour of Atom intermediaries. Given the absence of such rules, the next best way to ensure interoperability to understand the typical behaviour of Atom implementations: the fact that it is easier for some implementations to support Extension Elements in the 3 defined extension points than foreign attributes on every element in an Atom document; that this translates to more implementations supporting extension elements than attributes; and that this implies that an extension would be more interoperable if it chooses Section 6.4 markup over undefined foreign markup. -- Dave
Re: Feed Thread in Last Call
On May 17, 2006, at 12:46 PM, Byrne Reese wrote: Speaking up: http://www.majordojo.com/atom/ standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. Me too. Does something useful, does no harm, if it's broken in some way it'll be harmlessly routed around. I suspect that implementations that are stupid about the contents of atom:link will be fixed pretty soon. -Tim
Re: Feed Thread in Last Call
On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim
Re: Feed Thread in Last Call
+1. What Tim said. - James Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim
Re: Feed Thread in Last Call
I've had a hard time following this thread, but for what its worth I buy Tim's reasoning. +1 On May 23, 2006, at 12:26 PM, James M Snell wrote: +1. What Tim said. - James Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim
Re: Feed Thread in Last Call
At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim Sounds about right. Where do we stop then? If the marketplace decides, is there a need to submit the FTE to the IETF? Will any extensions need to be submitted? Only Atom per see needed to be standardised in such a case. - Sylvain
Re: Feed Thread in Last Call
At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote: At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim Sounds about right. Where do we stop then? If the marketplace decides, is there a need to submit the FTE to the IETF? Will any extensions need to be submitted? Only Atom per see needed to be standardised in such a case. Welcome to the messy world of standards. There might be a need for an updated FTE RFC. On the other hand, if the market gives a big yawn, there is probably no need to update the RFC if no one is using it. On the third hand, it doesn't hurt to have it updated anyway; there are lots of RFCs that have barely any implementations. There is probably a fourth hand consideration as well. There is no clear delineation point for when an extension should become an RFC. The IETF plays it by ear. For some protocols, lots of extensions as RFCs has been a boon; for others, just a bother. We won't know where the Atom format fits in that range for a few years. --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
Welcome to the messy world of standards. There might be a need for an updated FTE RFC. On the other hand, if the market gives a big yawn, there is probably no need to update the RFC if no one is using it. On the third hand, it doesn't hurt to have it updated anyway; there are lots of RFCs that have barely any implementations. There is probably a fourth hand consideration as well. There is no clear delineation point for when an extension should become an RFC. The IETF plays it by ear. For some protocols, lots of extensions as RFCs has been a boon; for others, just a bother. We won't know where the Atom format fits in that range for a few years. Thanks a lot for that honest answer Paul. Appreciated :) - Sylvain
Re: Feed Thread in Last Call
On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length) I'm going to re-organize David's argument a little and deal with one of his last points first. Foreign attributes are bad, and are inherently less interoperable than Extension Elements. I would say that furious debates about elements-vs-attributes have been going on since the dawn of XML in 1998, but that would be untrue; they've been going on since the dawn of XML's precursor SGML in 1986. They have never led anywhere. After you've noticed that if you need nested element structure you're stuck with elements, and if you don't want to have two things with the same names attributes can help, there really aren't any deterministic decision procedures. I note with pleasure that *all* known XML APIs allow you to retrieve elements and attributes with about the same degree of difficulty. So, my conclusion: I disagree with Powell. Let people put extensions wherever they feel like putting them (they will anyhow), remembering that human-readability is a virtue. If models try to micro-manage the element/attribute thing, those models are broken, don't use them. If software arbitrarily discards markup because the markup doesn't match its idiosyncratic ideas about elements and attributes, that software is non-comformant and non-interoperable. Software that deals with XML such as an XHTML document, doesn't have much choice but to model the document using generic XML concepts and tools - Infosets, DOM, SAX, strings containing XML tags, etc. For Atom though, it is useful to model feeds and entries in terms of some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF, but that is a dirty word around these parts). Well yes, but each and every one of those non-XML models fails to capture the information content of perfectly-legal XML in one way or another. The Atom data format *could* have been designed in such a way as to be conformant with one or more of those models, but it wasn't. Extensions to Atom can be designed in such a way as to fit into some particular data model, or not. So I think it's really questionable to try to normatively reverse engineer the WG consensus to try to pretend that Atom documents can usefully be processed as anything but XML. Section 6 of RFC4287 is flawed. It is an ugly mix I agree. In fact, what Simple Extension *really* says is this property can trivially be modeled in RDF and Structured Extension really says is doesn't directly map to RDF, but I failed to convince the WG either to remove this hand-waving or to be clear about what we really meant. Having said that, these notions fortunately have exactly zero normative effect on implementors. of my (overly) strict PaceExtensionConstruct proposal[1], and an (overly) liberal philosophy that the existence of foreign markup anywhere won't break implementations, so shouldn't be disallowed. I have no comment on your proposal, but the philosophy you describe does in fact represent the consensus of the WG and the IETF community; your opinion that it is overly liberal is interesting but not particularly relevant to implementors. atompub's charter states: Atom consists of: * A conceptual model of a resource * A concrete syntax for this model Extension elements are defined to have both a model and a syntax, but Atom's allowance for foreign attributes to appear anywhere is a case of syntax that has no corresponding model. Atom doesn't really explain what foreign attributes are intended for. Extension elements also, as noted above, have *no normative effect*. It is arguable that the design of Atom departed from the charter in that the model was never explicitly specified. To me, this seems like sound design; the success of the Web has been based on careful specification of the content and sequence of the interchanged messages without any attempt to standardize on a model. This is A Good Thing, and demonstrably works. And Atom also doesn't really explain what foreign elements are intended for either. It seems like they could be an extension point, but given that many implementations will have an application model that isn't based on the XML Infoset (as described above), There's a word for implementations (especially intermediaries, as you notice) that aren't based on the Infoset: broken. Because RFC4287 is explicitly defined only in terms of the infoset. Go ahead and try to impose any models that are appropriate for your application needs; I do this all the time. But don't change the Infoset. it seems very unwise to create an extension proposal which depends on the precise syntax of an element being preserved. The precise syntax claim is utterly bogus. RFC4287 properly standardizes at the Infoset level, thus it makes zero difference whether I say titleCafé/title or titleCaf#xe9;/title. I personally think that an extension
Re: Feed Thread in Last Call
On 5/23/06, Tim Bray [EMAIL PROTECTED] wrote: I would vociferously resist any such claim. OTOH, there are more than a few products on the market right now that back up just such a claim. So there's an existence proof, and most of the APIs I've seen *do* make use simple vs. structured, but you may be right that the market will change that. In otherwords, there is little point in continuing this discussion... just like you and I agreed 150+ messages ago... -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
Friday, May 19, 2006, 1:40:43 AM, Lisa Dusseault wrote: I've been trying to understand if there's a technical problem with the draft's chosen placement of the attributes and the best case I've seen is that that location is technically disallowed by RFC4287 , an assertion which is disputed (alas, natural language meanings are often disputed). Hmm, that wasn't my argument either... I fully agree that the attributes are technically allowed by both the text and RelaxNG of RFC4287. I don't think anyone is disputing that. Sorry for repeating myself again, but I'll recap my argument in full because it seems like it hasn't been understood. A bit of background: Modelling = Software that deals with XML such as an XHTML document, doesn't have much choice but to model the document using generic XML concepts and tools - Infosets, DOM, SAX, strings containing XML tags, etc. For Atom though, it is useful to model feeds and entries in terms of some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF, but that is a dirty word around these parts). Some of the reasons for this are: Most Atom implementations are concerned with the combined state of a feed over time, not the state of an individual feed document, so pure XML access is inadequate. More robust, and efficient implementations, particularly in the case of RDBMS. Implementations may be built upon existing systems, such as existing content management systems, where a mapping between Atom the XML syntax, and the entities in an existing system would need to be established. Even the best XML APIs are horrible to use when compared to domain specific APIs. Extensions == Atom standardised a minimal set of elements, with the expectation that any other elements would be created as extensions. It is therefore important that Atom infrastructure shouldn't get in the way of the deployment of extensions. Atom uses mustIgnore semantics for extensions, which allows implementations to copy-through extensions even if they don't understand their purpose. Section 6 of RFC4287 is flawed. It is an ugly mix of my (overly) strict PaceExtensionConstruct proposal[1], and an (overly) liberal philosophy that the existence of foreign markup anywhere won't break implementations, so shouldn't be disallowed. [1] http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct?action=recalldate=1105566248 I complained about it here[2], admittedly a long time after IETF last call, but as we were still making Atom 101 changes about then (eg: let's allow multiple authors), maybe that wasn't so unreasonable. It doesn't make any sense to define two very precise classes of extension element, and then say that any extra markup can go anywhere, without giving any justification or explanation to why we did this, or any guidelines to why extension authors should pick each of these options. [2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html Unfortunately Simple Extension elements are too unconstrained to fulfil their original objective, so the difference between them and Structured Extensions is academic. The intent was that Simple Extensions were a class of extension whose values were context-free strings that would be easy to implement, and easy to provide UIs for, and extension proposers might be encouraged to choose this class of extension where it was appropriate for improved interoperability. I don't think that this worked out. The difference between extension elements, and foreign attributes is significant however. atompub's charter states: Atom consists of: * A conceptual model of a resource * A concrete syntax for this model Extension elements are defined to have both a model and a syntax, but Atom's allowance for foreign attributes to appear anywhere is a case of syntax that has no corresponding model. Atom doesn't really explain what foreign attributes are intended for. It seems like they could be an extension point, but given that many implementations will have an application model that isn't based on the XML Infoset (as described above), it seems very unwise to create an extension proposal which depends on the precise syntax of an element being preserved. The intent of Simple Extensions was to provide a class of extension that was more interoperable; foreign attributes appear to provide a class of extension (if that is what it is) that will be much less interoperable. Some guidance in how to design extensions is definitely missing from the RFC, perhaps an Informational RFC explaining the issues would be appropriate. Relevance of intermediaries === Most of these issues only apply to Atom intermediaries: agents which much accept Atom documents, and represent the documents internally without losing information. It doesn't matter if a desktop aggregator drops extensions if it has no UI for displaying them anyway. But I think that the class of Atom intermediaries will become
Re: Feed Thread in Last Call
On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Am I missing something in the case against the choice of location for the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in implementations who won't parse them. I think I've made that extremely clear. The previous draft addressed my concerns. My current plan is to implement the threading element, but I'll recommend against accepting bug reports on the other aspects of the document, since I think it's an underspecified mess. Kind of silly considering the clear lessons from earlier efforts, but the threading element is good enough. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Am I missing something in the case against the choice of location for the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. - James
Re: Feed Thread in Last Call
On 5/19/06, James M Snell [EMAIL PROTECTED] wrote: Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. You've received several of those from me. I suggest you read your old mail, paying close attention to messages that you replied to in under 15 minutes. I have zero confidence that any technical change or compromise is possible from you, and I find interacting with you to be a giant time sink. My new policy will be to explain my problem *once*, and then I will verify that my concerns (if any) have been addressed at some later date when there is a revised document available. If my concerns aren't addressed, I will make a concerted effort to avoid writing or being responsible for maintaining any relevant functionality. -- Robert Sayre
Re: Feed Thread in Last Call
The latter is, of course, not specific to FTE, but apparently is enough of a problem to at least warrant a mention. Thank you. This is fully appreciated. - Sylvain
RE: Feed Thread in Last Call
When Friendster approached Six Apart and asked for a way to keep abreast as to the comment activity within the Friendster Blogging network (powered by TypePad), I turned immediately to FTE. In this implementation, there was actually no desire for Friendster to gain access to the comments themselves - all they wanted was to know: has there been a new comment posted to any of this users blog entries? And in actually, TypePad didn't want to add another page to be rebuilt. We wanted to keep things as simple as possible, in order to satisfy the customer's requirements within incurring any more development overhead than absolutely necessary. FTE was a perfect fit because it allowed Friendster to monitor comment activity quite reliably. The count attribute wasn't enough for them because the count attribute by itself doesn't reflect accurately if a new comment was posted (e.g. comment count is 0, new comment received, comment count is 1, comment deleted, comment count is 0, comment received, etc). Depending upon the poll interval of the client, it may miss the fact that a comment was posted. However, the count attribute and then when attribute gave Friendster just what they needed: enough information to know that a) a new comment was received, and b) sufficiently (not necessary 100% accurate, but they didn't care) accurate comment count. They used this information to send emails to the blog owner saying, since we last emailed you, there has been this activity on your blog. The Friendster link relation looks like this: link rel=replies type=text/html href=http:///foo.html#comments; thr:when=date thr:count=int / Notice, in this case we are pointing to the HTML page where comments can be found - and not to another Atom feed because we don't produce a comments feed. We simply produce some meta data about comment activity. Furthermore, Six Apart likes this spec as-is because it helps to reduce the number of documents that need to be parsed in order to determine simple details about an entry. The burden of having to fetch an Atom document for each entry and then counting the number of entries within that feed to derive a count, is totally absurd. If you CAN make it easier for a developer, why won't you? Well you simply move the burden to a different level where it is not your problem anymore, ie on the HTTP level and far from the application level. It is fine but the load will be paid by someone at any given time. Not to mention that in Friendster's case, this process would not have worked for them because we didn't produce a feed for them to extract this information from, because their requirements forbade it. I have gone on long enough. I am hoping this gave some good background around a real implementation and use case currently in use today. You did and I thank you for sharing this information. That being said, I raised two points in me original mail: 1. The fact I thought the thr attributes were useless. You made a good case and I will not fight against their use on the application level anymore. We are therefore fine on *that* level. 2. The burden added to the HTTP layer. I'll try to make myself clear. In your implementation above you have to update the Atom feed to modify the thr attributes. The problem is that you have then to update the last modified date of the resource (as in the REST definition of resource) itself (whether you generate ir on the fly or save it on disk). For aggregators which are aware of the FTE, it won't be so much of a problem as you showed me because they will know how to deal with that on the application level and make the best of it. However, there will be clients which won't care about the semantic of the resource, their point is simply to fetch a resource and cache it as long as it is not modified. By acting as you do, we may end up in a huge amount of feeds being sent on the wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they will not handle anyway). This is my grief. Your use case is great at the application level but could really mess bandwith usage as well. That's why I also say you have moved the burden down to one level so that it doesn't make your life more complicated and so that others pay the price of it. I'd be interested to hearing from Friendster about their feed bandwith usage since you have setup the FTE. However I'm not blind enough either to realise my algorithm would not be much better in some circumstances. I guess my problem is that the semantic conveyed by those attributes should belong to a push protocol and not to a pulled one like HTTP. I aslo understand that Atom and its extensions are not protocol aware. They should not have to care about HTTP. It does not mean though that we cannot think about their implications in those areas. Thanks for your feedback. - Sylvain
Re: Feed Thread in Last Call
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. That doesn't accurately state my problem with FTE. My concern is more general than the compatibility with a specific Atom implementations. The fact that the MS feed platform exhibits the issue is just a confirmation that the issue is more than a theoretical concern. An implementor that wants to /consume/ Atom (such as a feed API, or store), ought to be able to create an accurate implementation just by reading RFC4287. That document describes what properties entries, feeds, links, and extension elements have, and how they are represented in an Atom document. Using this it is possible to create a database schema or OO API that can represent feed data. My problem with FTE is that rather than using Atom's extension-point: the Extension Element (which an implementor of RFC4287 is likely to be capable of preserving), it uses the fact that Atom doesn't prohibit extra attributes to be included anywhere in the document. Is an API, feed store, or Atom Protocol implementation expected to preserve every attribute on every element, in addition to the core elements, and extension points? This might be practical on a few green-field Atom implementations, but it wouldn't be practical on systems than need to be retrofitted to support Atom. What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. Atom implementations with generic support for links and extensions, will find that this draft moves the goalposts of what a reasonable implementation is expected to handle, and I firmly believe that it should be possible for implementations to provide generic support for extensions in order to assist their adoption. Part of the problem might be caused by flaws in Atom's extensibility model, but that is all the more reason for extensions to be conservative in its use. None of the folks I know of that have actually implemented support for the extension has had any problems with them. Does that include any stateful feed APIs, or APP servers that aren't based on native XML back-ends? I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. -- Dave
Re: Feed Thread in Last Call
By acting as you do, we may end up in a huge amount of feeds being sent onthe wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they willnot handle anyway). Servers don't *have* to change the feed's Last-Modified and ETag values when a comment count changes. They are free to respond 304 to a conditional GET, even if the count has changed. Hugh
Re: Feed Thread in Last Call
By acting as you do, we may end up in a huge amount of feeds being sent on the wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they will not handle anyway). Servers don't *have* to change the feed's Last-Modified and ETag values when a comment count changes. They are free to respond 304 to a conditional GET, even if the count has changed. Well this is debatable because you effectively change the resource itself and ought to update its meta-data as well (ie Last-Modified and Etag values). Besides, by not doing so can be even worse because an aggregator would requests the feed, the server would respond with a 304 and the aggregator would not even know the count ahs changed in the end. It feels even worse. - Sylvain
Re: Feed Thread in Last Call
Well this is debatable because you effectively change the resource itself and ought to update its meta-data as well (ie Last-Modified and Etag values). Besides, by not doing so can be even worse because an aggregator would requests the feed, the server would respond with a 304 and the aggregator would not even know the count ahs changed in the end. It feels even worse. Actually the aggregator could NOT send the If-Modified-Since header of course in that specific case and be safe. But this seems like a bit of an abuse of HTTP to me. - Sylvain
Re: Feed Thread in Last Call
On Thu, May 18, 2006 at 09:26:18AM +0100, Sylvain Hellegouarch wrote: By acting as you do, we may end up in a huge amount of feeds being sent on the wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they will not handle anyway). It's a valid concern, but as James has been saying the problem is with the syndication model. This isn't something that Atom (or any extension) can solve. Do you have any suggestions about how this metadata could be included without changing the content of the feed? AFAICT the only solution is to not use the attributes (which aren't required, of course). pgpu55TsuM4hr.pgp Description: PGP signature
Re: Feed Thread in Last Call
It's a valid concern, but as James has been saying the problem is with the syndication model. This isn't something that Atom (or any extension) can solve. I agree with you and James. This is much larger issue and this spec is not the right place to try solving it. Do you have any suggestions about how this metadata could be included without changing the content of the feed? AFAICT the only solution is to not use the attributes (which aren't required, of course). I'll make a fool of myself after being so virulent but apart from a fairly big change in the Internet architecture. There is little that could be done to solve the problem of polling Vs pushing. That being said, I would not be surprised that ISPs push really hard for such a discussion to happen as they will soon be overloaded by the huge amount of data passing on the wires they pay for (thinks much larger than just feeds like HDTV ;). Anyway, no I don't have a better solution. I am nevertheless happy that the point will be notified by James in its draft. - Sylvain
Re: Feed Thread in Last Call
And I am sorry for the numerous mistakes I make in my written English. *sigh*
Re: Feed Thread in Last Call
David,
David Powell wrote:
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
That doesn't accurately state my problem with FTE. My concern is more
general than the compatibility with a specific Atom implementations.
The fact that the MS feed platform exhibits the issue is just a
confirmation that the issue is more than a theoretical concern.
My apologies for the misrepresentation. It was unintentional.
An implementor that wants to /consume/ Atom (such as a feed API, or
store), ought to be able to create an accurate implementation just by
reading RFC4287. That document describes what properties entries,
feeds, links, and extension elements have, and how they are
represented in an Atom document. Using this it is possible to create a
database schema or OO API that can represent feed data.
When I look at RFC4287 I see the following statements:
1.3 : Some sections of this specification are illustrated with
fragments of a non-normative RELAX NG Compact schema
[RELAX-NG]. However, the text of this specification provides
the definition of conformance.
4.2.7 : The atom:link element defines a reference from an entry or
feed to a Web resource. This specification assigns no meaning
to the content (if any) of this element.
6.1 : Markup from other vocabularies (foreign markup) can be used
in an Atom Document.
6.3: Atom Processors that encounter foreign markup in a location
that is legal according to this specification MUST NOT stop
processing or signal an error.
6.4: Atom allows foreign markup anywhere in an Atom document, except
where it is explicitly forbidden.
Further, the RELAX NG definition for atom:link is,
atomLink =
element atom:link {
atomCommonAttributes,
attribute href { atomUri },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { atomLanguageTag }?,
attribute title { text }?,
attribute length { text }?,
undefinedContent
}
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute =
attribute * - (xml:base | xml:lang | local:*) { text }
undefinedContent = (text|anyForeignElement)*
My interpretation of the text and the RELAX NG definition is that while
the specification does not assign any meaning to extensions of the link
element, it is nonetheless explicitly allowed.
It may have been a mistake, but the discussion of section 6.4 is
explicitly scoped *only* to child elements of atom:entry, atom:feed,
atom:source and Person constructs. Note that this section does NOT state
that ONLY those elements may be extended; rather, the section defines
the characteristics of two types of extensions that could occur on those
subsets of elements. The characteristics of extensions on other
elements in the Atom vocabulary are left undefined.
The definitions of the atomCommonAttributes (which allows any number of
undefinedAttributes and the definition of undefinedContent is very
clear on the point that extensions ARE allowed on Link. Such extensions
may not be semantically meaningful to RFC4287, but they are nonetheless
legal and a valid component of the Atom data model.
[snip]
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of RFC4287 there is no problem
with the draft, but practically there is something like a layering
concern if an extension requires existing conformant implementations
to be changed.
Atom does not define any notion of conformance. That is, there are no
requirements anywhere that define what aspects of the Atom data model an
implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to
expect that different implementations will offer varying levels of
support for a variety of the core features offered by the protocol. For
instance, Atom's data model allows for multiple enclosure links. In my
Atom implementation, this is easily handled and exposed by the API; in
Microsoft's implementation, however, only a single enclosure is exposed.
Some implementations do not expose any link other than the first
alternate link that they happen to find in the entry.
I'm sure there are countless such examples. Some implementations don't
use/preserve the scheme attribute on the category element; some
implementations don't fully support the atom content model (e.g. base64
encoded content); some implementations don't support XML digital
signatures; etc.
Because there is no
Re: Feed Thread in Last Call
* James M Snell [EMAIL PROTECTED] [2006-05-18 17:40]: My interpretation of the text and the RELAX NG definition is that while the specification does not assign any meaning to extensions of the link element, it is nonetheless explicitly allowed. Noone ever debated that. It may have been a mistake, but the discussion of section 6.4 is explicitly scoped *only* to child elements of atom:entry, atom:feed, atom:source and Person constructs. That was a mistake, yes. Unfortunately, hindsight is 20/20. Note that this section does NOT state that ONLY those elements may be extended; rather, the section defines the characteristics of two types of extensions that could occur on those subsets of elements. The characteristics of extensions on other elements in the Atom vocabulary are left undefined. Yes. That means extending other elements is a free-for-all just as it is in RSS 2.0, and we know the problems that this poses in practice. Extending Atom in ways other than those defined in Sec 6.4. has the same problems as extending RSS 2.0 with namespaced elements. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
Look at that giant email. Seems to me that it's a debate taking place
for no discernable reason. There's no technical reason for the
placement of the attributes, and management has made it clear that any
objections are irrelevant.
Hope that helps!
On 5/18/06, James M Snell [EMAIL PROTECTED] wrote:
David,
David Powell wrote:
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
That doesn't accurately state my problem with FTE. My concern is more
general than the compatibility with a specific Atom implementations.
The fact that the MS feed platform exhibits the issue is just a
confirmation that the issue is more than a theoretical concern.
My apologies for the misrepresentation. It was unintentional.
An implementor that wants to /consume/ Atom (such as a feed API, or
store), ought to be able to create an accurate implementation just by
reading RFC4287. That document describes what properties entries,
feeds, links, and extension elements have, and how they are
represented in an Atom document. Using this it is possible to create a
database schema or OO API that can represent feed data.
When I look at RFC4287 I see the following statements:
1.3 : Some sections of this specification are illustrated with
fragments of a non-normative RELAX NG Compact schema
[RELAX-NG]. However, the text of this specification provides
the definition of conformance.
4.2.7 : The atom:link element defines a reference from an entry or
feed to a Web resource. This specification assigns no meaning
to the content (if any) of this element.
6.1 : Markup from other vocabularies (foreign markup) can be used
in an Atom Document.
6.3: Atom Processors that encounter foreign markup in a location
that is legal according to this specification MUST NOT stop
processing or signal an error.
6.4: Atom allows foreign markup anywhere in an Atom document, except
where it is explicitly forbidden.
Further, the RELAX NG definition for atom:link is,
atomLink =
element atom:link {
atomCommonAttributes,
attribute href { atomUri },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { atomLanguageTag }?,
attribute title { text }?,
attribute length { text }?,
undefinedContent
}
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute =
attribute * - (xml:base | xml:lang | local:*) { text }
undefinedContent = (text|anyForeignElement)*
My interpretation of the text and the RELAX NG definition is that while
the specification does not assign any meaning to extensions of the link
element, it is nonetheless explicitly allowed.
It may have been a mistake, but the discussion of section 6.4 is
explicitly scoped *only* to child elements of atom:entry, atom:feed,
atom:source and Person constructs. Note that this section does NOT state
that ONLY those elements may be extended; rather, the section defines
the characteristics of two types of extensions that could occur on those
subsets of elements. The characteristics of extensions on other
elements in the Atom vocabulary are left undefined.
The definitions of the atomCommonAttributes (which allows any number of
undefinedAttributes and the definition of undefinedContent is very
clear on the point that extensions ARE allowed on Link. Such extensions
may not be semantically meaningful to RFC4287, but they are nonetheless
legal and a valid component of the Atom data model.
[snip]
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of RFC4287 there is no problem
with the draft, but practically there is something like a layering
concern if an extension requires existing conformant implementations
to be changed.
Atom does not define any notion of conformance. That is, there are no
requirements anywhere that define what aspects of the Atom data model an
implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to
expect that different implementations will offer varying levels of
support for a variety of the core features offered by the protocol. For
instance, Atom's data model allows for multiple enclosure links. In my
Atom implementation, this is easily handled and exposed by the API; in
Microsoft's implementation, however, only a single enclosure is exposed.
Some implementations do not expose any link other than the first
alternate link that they happen to find in the entry.
I'm sure there are
Re: Feed Thread in Last Call
* Robert Sayre [EMAIL PROTECTED] [2006-05-18 18:05]: There's no technical reason for the placement of the attributes, Do you have better ideas on how to provide this information on a per-link basis? It would help if you actually tried to suggest an approach instead of bashing what’s there. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On May 18, 2006, at 8:10 AM, Brendan Taylor wrote: Do you have any suggestions about how this metadata could be included without changing the content of the feed? AFAICT the only solution is to not use the attributes (which aren't required, of course). If it's in the feed document and it gets updated other than when the entry itself is updated (...and it wouldn't be of much use if it were only updated when the entry was updated), it's going to result in data getting re-fetched when nothing but the comment count and timestamp change. I don't see any way around that. So if you really want a way to publish comment counts and timestamps without causing lots of unchanged data from getting refetched, you're going to have to separate that data out of the feed. Here's pseudo-XML for a possible approach: feed ... ... link rel=comment-tracking href=... / ... entry idfoo/id ... /entry entry idbar/td ... /entry ... /feed and in another document: ct:comment-tracking xmlns:ct=... xmlns:atom=... ... atom:link rel=related href=URL of the feed ... / ct:entry ref=foo atom:link rel=comments href=... type=... hreflang=... ct:count=5 ct:when=... / atom:link rel=comments href=... type=... hreflang=... ct:count=3 ct:when=... / /ct:entry ct:entry ref=bar atom:link rel=comments href=... type=... hreflang=... ct:count=0 ct:when=... / atom:link rel=comments href=... type=... hreflang=... ct:count=1 ct:when=... / /ct:entry ... /ct:comment-tracking Of course the comment tracking document wouldn't only be authoritative for feeds that pointed to it with a comment-tracking link. This would require an extra subscription to track the comments, as well as understanding an additional format (as opposed to just an additional extension--either approach requires SOME additional work), but it would prevent unnecessary downloads by clients that aren't aware of it, and would reduce the bandwidth used by those that are. This approach could be generalized to enable offloading of other metadata that's more volatile than the entries themselves. Antone
Re: Feed Thread in Last Call
* Antone Roundy [EMAIL PROTECTED] [2006-05-18 20:05]: and in another document: ct:comment-tracking xmlns:ct=... xmlns:atom=... ... atom:link rel=related href=URL of the feed ... / ct:entry ref=foo atom:link rel=comments href=... type=... hreflang=... ct:count=5 ct:when=... / atom:link rel=comments href=... type=... hreflang=... ct:count=3 ct:when=... / /ct:entry ct:entry ref=bar atom:link rel=comments href=... type=... hreflang=... ct:count=0 ct:when=... / atom:link rel=comments href=... type=... hreflang=... ct:count=1 ct:when=... / /ct:entry ... /ct:comment-tracking Of course the comment tracking document wouldn't only be authoritative for feeds that pointed to it with a comment-tracking link. This would require an extra subscription to track the comments, as well as understanding an additional format (as opposed to just an additional extension--either approach requires SOME additional work), but it would prevent unnecessary downloads by clients that aren't aware of it, and would reduce the bandwidth used by those that are. This approach could be generalized to enable offloading of other metadata that's more volatile than the entries themselves. Actually, you don’t really need another format. There’s no reason why you couldn’t use atom:feed in place of your hypothetical ct:comment-tracking. :-) Your ct:entry elements could almost be atom:entry ones instead, too, except that assigning them titles and IDs feels like overkill. The real cost is not the cost of an extra format, but that implementations then need to understand the FTE in order to know to poll an extra document to retrieve the out-of-band metadata. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On May 18, 2006, at 12:31 PM, A. Pagaltzis wrote: Actually, you don’t really need another format. There’s no reason why you couldn’t use atom:feed in place of your hypothetical ct:comment-tracking. :-) Your ct:entry elements could almost be atom:entry ones instead, too, except that assigning them titles and IDs feels like overkill. The point of the whole exercise is to create a lightweight document for volatile metadata. If it's an atom:feed, you have to include a lot of stuff that's not needed here--atom:title, atom:updated, atom:author, and atom:summary or atom:content. Also, you'd need to have an atom:id for each entry in addition to the @ref pointing to the entry that it talks about. The real cost is not the cost of an extra format, but that implementations then need to understand the FTE in order to know to poll an extra document to retrieve the out-of-band metadata. Sure, but if they don't understand FTE, they wouldn't know what to do with the extra metadata anyway even if it were in the main feed. They MIGHT be able to do some generic processing of the comments link, but the reliability of any generic processing algorithm for unknown link types is questionable since we left atom:link open to all sorts of uses. And you COULD keep the comments links in the main feed but just leave off @count and @when for the benefit of apps that don't process the sibling document. On May 18, 2006, at 11:48 AM, Antone Roundy wrote: This approach could be generalized to enable offloading of other metadata that's more volatile than the entries themselves. I don't know yet what other metadata might be handled this way, but here's slightly revised pseudo-XML that makes it more general and adds a few useful things: feed ... idfoobar/id ... link rel=volatile href=... / ... entry idfoo/id ... /entry entry idbar/td ... /entry ... /feed v:volatile ref=foobar xmlns:v=... xmlns=http://www.w3.org/2005/ Atom xmlns:thr=...!-- @ref could be omitted if using with RSS -- link rel=related href=URL of the feed ... /!-- don't really need something different from related, right? -- updated.../updated v:entry ref=foo!-- @ref could be a guid if using with an RSS 2.0 feed, though we all know that RSS 2.0 guids are misused in ways that might make the connection unreliable -- updated.../updated link rel=comments href=... type=... hreflang=... thr:count=5 thr:when=... / link rel=comments href=... type=... hreflang=... thr:count=3 thr:when=... / /v:entry v:entry ref=bar updated.../updated link rel=comments href=... type=... hreflang=... thr:count=0 thr:when=... / link rel=comments href=... type=... hreflang=... thr:count=1 thr:when=... / /v:entry ... /v:volatile
Re: Feed Thread in Last Call
* Antone Roundy [EMAIL PROTECTED] [2006-05-18 21:40]: The point of the whole exercise is to create a lightweight document for volatile metadata. If it's an atom:feed, you have to include a lot of stuff that's not needed here--atom:title, atom:updated, atom:author, and atom:summary or atom:content. Also, you'd need to have an atom:id for each entry in addition to the @ref pointing to the entry that it talks about. I did say that atom:entry is overkill. You could still use a feed document, though. If you have no atom:entry in it you can elide the feed-level atom:author, and the other required elements for a feed (atom:id and atom:updated) seem like a good idea to have in this sort of document. Only atom:title is unnecessary, but that does not feel like a big burden. Sure, but if they don't understand FTE, they wouldn't know what to do with the extra metadata anyway even if it were in the main feed. That is only half correct. The point of Sec 6.4 is to allow intermediaries at the infrastructure level (which includes things like the RSS Platform) to store and pass on extension metadata generically, without having to understand what a particular extension means. If you put this metadata out of band, then the application layer has to take on infrastructure layer responsibilities. Note that I’m not arguing against the approach. It seems like an interesting idea. I’m just pointing out that it does have costs. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
a:f id=idoffeed a:ds=1a:e id=idofentry a:r=2a:c id=idofcomment a:r=1a:c id=idofcomment a:r=2/ /a:c/a:ea:e id=idofentry: a:r=3//a:fThe requestor sends a request for all entries and comments on those entiries since a certain date. If the date request is considered reasonable, a compact atom syntax that contains, a) a determination as to whether they support providing diffs a:ds=0 false, a:ds=1, trueb) the relavent pieces necessary to determine if,b:1) you have a local instance of that id. b:1:1) If yes, compare the revision (a:r) value. b:1:1:1) If the same, ignore, b:1:1:2) if different, the difference is determined, and stored until the compact syntax above has finished being processed.b:1:2) If there is no local instance of that id, store the this until the process has finished.recurse until complete.recurse the result:a: If you can process the diff, and they support returning just the diff, set a request header determined to specify this to the server. b: set a header to specify to the server if you want the exact specified revision, or additional revisions if they have changed since the original query.c: return a request for each updated or new resource, with the difference between the local revision number and the revision number on the server if appropriate. each request is initially atomic, with the ability to be grouped if the server determines that it would be more efficient at present time to handle one request at a time, or grouped together using a conanical compression of the requested items. This would be returned in the response header such as to maintain a consistent ability to adapt at any moment to current oad on the server. nothing is approximate, each side of the transaction has the ability to adapt to change, and to decide if it wants to handle potential differences that take place during the span between requests now, or at a later date. With each transaction, enough information is provided to quickly calculate and determine, or specify a default if the current load is past a certain threshold, while still maintaining the knowledge that updates exists, and when the load allows, make a new request based on the difference in stored values that pertain to each id it has knowledge to have differences. If during this span, the server in which receives the request realizes that since the last request, a resource has been removed/deleted, a header can be set to specify that future calculations should be based on the new difference instead of the old. In the above scenario the amount of data exchange is at a bare minimum, the processing required to calculate the differences is at a bare mininum, it maintains a level of data integrity that is granular enough to adapt to each change in the system, without requirement of extensive processing to determine this difference, while maintaining an agile/adaptible foundation that can adjust as needed without loss of data integrity on either side of the transaction. Given the amount of data sent with initial request is at a bare minimum, this can be set in memory as the default response based on the time difference to determine the address of where to begin streaming the request, using the default a:f id=feedid to open/close the response stream at the appropriate start and stop point of the returned stream. Please disregard the above if I have left out obvious areas in which makes this irrelevant. Not trying to take a this is the absolute right way to do this and instead inject the smallest, simplest path that seems to logically provide the necessary pieces to make the transaction processing of differences as simple and efficient as possible, while doing so in a way thats just outside the box, but close enough as to not require any changes to any actual draft specifications, and instead a way to illiminate some of the concerns presented that suggested potentials areas of inefficient or innacurate behaviors that hold potential for problems down the road. Peace :)On 5/18/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Antone Roundy [EMAIL PROTECTED] [2006-05-18 20:05]: and in another document: ct:comment-tracking xmlns:ct=... xmlns:atom=... ... atom:link rel=related href="" of the feed ... / ct:entry ref=foo atom:link rel=comments href="" type=... hreflang=...ct:count=5 ct:when=... / atom:link rel=comments href="" type=... hreflang=...ct:count=3 ct:when=... / /ct:entry ct:entry ref=bar atom:link rel=comments href="" type=... hreflang=...ct:count=0 ct:when=... / atom:link rel=comments href="" type=... hreflang=...ct:count=1 ct:when=... / /ct:entry ... /ct:comment-tracking Of course the comment tracking document wouldn't only be authoritative for feeds that pointed to it with a comment-tracking link. This would require an extra subscription to track the comments, as well as understanding an additional format (as opposed to just an additional extension--either approach requires SOME additional work), but it would prevent unnecessary downloads by
Re: Feed Thread in Last Call
On May 18, 2006, at 8:56 AM, Robert Sayre wrote: Look at that giant email. Seems to me that it's a debate taking place for no discernable reason. There's no technical reason for the placement of the attributes, and management has made it clear that any objections are irrelevant. I realize that the placement of the attributes is one choice among many. Sometimes you just have to make a choice and there's no reason beyond it needs to go somewhere. I've been trying to understand if there's a technical problem with the draft's chosen placement of the attributes and the best case I've seen is that that location is technically disallowed by RFC4287, an assertion which is disputed (alas, natural language meanings are often disputed). Am I missing something in the case against the choice of location for the metadata? Thanks, Lisa
Re: Feed Thread in Last Call
Hello Robert, It's not the IETF which wants to move this on on Standards Track, it's (currently) James as an individual submitter. The IESG just did what it does for all such requests from individuals: Put the document out for IETF Last Call and tell the relevant mailing lists about it. Now it's your (and everybody else's) turn to tell the IESG what you think about this draft. A short, but clearly argued and nicely worded mail, with some easy-to-follow pointers to further material, is all that is needed. This may say okay with Standards Track iff these things get fixed or should be experimental because ... or even too controversial for an individual submission, needs a WG. The time you invest in this email will be a lot better spent than writing yet another mail to James and this list. Lisa (the sponsoring AD) and the rest of the IESG will then look at all the input they get, and will make a decision. Regards,Martin. At 07:03 06/05/17, Robert Sayre wrote: On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre
Re: Feed Thread in Last Call
[snip] - We're talking about adding machine-parsable data that would be invisible to readers of the post content I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. Machine-parseable data that may or may not be presented to users. The spec is silent on how the metadata should be used because there is no reason to dictate how it should be used. Implementations should use it in whatever way they feel is most appropriate. I'm sorry to stir this up again but I've read once more the last FT draft and I still cannot understand the use of the thr:count and thr:when attributes. Well in regards to the context they sit I see their meaning but I cannot see their value. If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. Besides, say a comment is added to the comments feed. I, as an application developer, will want to update thr:count and thr:when of the entry itself. Meaning that I will have to disregard any If-Modified-Since header sent by an aggregator to check out if my entry has changed when it has actually not changed per se. Anyway, I do not see the value brought by thr:count and thr:when alltogether. Since it is a MAY as well, I hardly see the point of keeping them. Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. Finally, if I set a link rel=replies ... / into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries. - Sylvain
Re: Feed Thread in Last Call
* Eric Scheid [EMAIL PROTECTED] [2006-05-17 14:25]: would this mean this is possible: entry link rel=replies thr:count=5 xml:lang=en href=1 / link rel=replies thr:count=1 xml:lang=fr href=1 / ... /entry You mean `hreflang`, not `xml:lang`, right? I have to say at first blush I don’t see why it should not work, so I find your thought experiment quite amusing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: You mean `hreflang`, not `xml:lang`, right? oops, yes. I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. :-)
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. I have no idea what you mean by not precise enough to be used. What makes them imprecise? Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? [snip] Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. The spec is silent on this, handle it however you want to handle it in your implementation. IMHO, Good implementations will silently ignore links they don't understand. Finally, if I set a link rel=replies ... / into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries. The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. - James
Re: Feed Thread in Last Call
I have no idea what you mean by not precise enough to be used. What makes them imprecise? The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. Clients could of course work around such issue but this is a rather big problem to me. The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. Common sense is one thing, being clearly specified is another one. - Sylvain
Re: Feed Thread in Last Call
The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. By the way, don't get me wrong. I am really looking forward to the FTE replies element but not its attributes which are just useless and counter productive to my liking. - Sylvain
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: I have no idea what you mean by not precise enough to be used. What makes them imprecise? The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. The values are no more or less trustworthy than the link's own type, length, and hreflang attributes. I refer you to http://www.w3.org/2001/tag/doc/mime-respect-20060412 Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? If you need an exact count, go to the linked resource. Feed publishers should take steps to ensure that the count is accurate. Again, read the W3C Tag finding referenced above. Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. HTTP provides a possible solution to this in the form of a weak entity tag. Also, Feed delta encoding could be leveraged to further mitigate the potential issues. Clients could of course work around such issue but this is a rather big problem to me. I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. - James
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: entry link rel=replies thr:count=5 xml:lang=en href=1 / link rel=replies thr:count=1 xml:lang=fr href=1 / ... /entry You mean `hreflang`, not `xml:lang`, right? I also meant there to be different hrefs too :-( entry link rel=replies thr:count=5 hreflang=en href=1 / link rel=replies thr:count=1 hreflang=fr href=2 / ... /entry e.
Re: Feed Thread in Last Call
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e.
Re: Feed Thread in Last Call
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. this should be amusing too: entry link rel=replies thr:count=5 href=1 title=trackbacks! / link rel=replies thr:count=1 href=2 title=comments! / ... /entry e.
Re: Feed Thread in Last Call
Yes. This is possible. What I'm not sure about is whether amusing is good or bad. What point are you trying to make exactly? - James Eric Scheid wrote: On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to say at first blush I don¹t see why it should not work, so I find your thought experiment quite amusing. this should be amusing too: entry link rel=replies thr:count=5 href=1 title=trackbacks! / link rel=replies thr:count=1 href=2 title=comments! / ... /entry e.
Re: Feed Thread in Last Call
Can't you just ignore them then? The feed update / last-modified issue is not isolated to the use of thr:when and thr:count. As I mentioned in another note, you end up with the exact same problem when folks use the slash:comments element but no one seems to mind that. This problem is not unique to FTE, nor does FTE make the problem any worse. What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. - Sylvain
Re: Feed Thread in Last Call
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Apache would respond: well yes the file has changed on the disk so here it is when in fact the content of the feed has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e. I'm not sure you have understood me. I'm not talking about the application level but from the HTTP level. If we update the feed each time we update the thr attributes then we screw the HTTP cache big time and waste bandwith. If we don't update them to avoid that issue then those attributes are just useless. Personally I have no interest in doing either way. - Sylvain
Re: Feed Thread in Last Call
HTTP provides a possible solution to this in the form of a weak entity tag. Also, Feed delta encoding could be leveraged to further mitigate the potential issues. ETag are not reliable without If-Modified-Since header and they are not as wide spreaded. I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. This is rather sad. So because others are broken we should not do better. - Sylvain
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. This is rather sad. So because others are broken we should not do better. No. I'm only just trying to solve one problem at a time. - James
Re: Feed Thread in Last Call
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-17 20:10]: However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: Consider the situation where a weblog only has a single global comments feed – which I strongly favour because having one of them for each entry just does not scale. Then it’s easily possible for some comments to have fallen of the bottom of the comments feed by the time you fetch it to check. In that case, the information in the attributes will be more accurate than the process you describe. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: [snip] What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. Do you feel the same way about the link element's existing type, title, hreflang, and length attributes? Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. This boils down to an implementation choice. The thr attributes provide a way for UI's to display something before fetching the feed, which is often useful for an individual to decide whether or not it is even worthwhile to fetch to the comments feed in the first place. Also, consider that comment feeds may span multiple pages (using the paging link rels). With your algorithm (which, yes, is the only authoritative way of determining *exactly* how many comments have been received), you would have to retrieve every page and count up the comments. Considering also that feeds do not necessarily have to be ordered chronologically (tho most are) and that the feed may contain comments to multiple entries, getting a precise count of the total number of comments can be a time and resource consuming process that involves examining every individual entry in the feed for the presence of a matching in-reply-to link. Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. - James
RE: Feed Thread in Last Call
Speaking up: http://www.majordojo.com/atom/standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell Sent: Monday, May 15, 2006 3:15 PM To: atom-syntax Subject: Feed Thread in Last Call Hey all, I'm happy to announce that the Feed Thread extension (draft -10) [1] has entered Last Call. [2] The thr:count and thr:when extension attributes are back in Draft -10 following the recent on-list discussion and post by Tim Bray affirming that the atom:link element is indeed extensible. I fully recognize that not everyone on list agrees with this approach, but after trying to propertly implement alternatives, re-reading RFC4287 and surveying folks who I know have already done the work necessary to implement Feed Thread, I believe the decision to keep thr:when and thr:count as attributes is the right decision. At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I have also added Feed Thread support to my Wordpress and Roller blog templates. IBM has plans to ship at least one product with Feed Thread support in the not too distant future (our Atom Publishing Protocol interop/test endpoint currently contains support for Feed Thread). If you do or do not want to see Feed Thread move forward as a Proposed Standard, now is the time to step up and make your case. :-) - James [1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1 0.txt [2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddT ag=13577rfc_flag=0
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: That's certainly one way of doing things, but not the only way. I'm fairly sure there are existing clients that rely on the thread count (using slash:comments) to determine whether a replies feed has changed. This makes sense when there is a separate feed for each reply - instead of connecting to dozens of feeds looking for updates (and hoping they support 304), you just download the main feed looking for a change in the thread count. If you don't like these attributes, that's fine - nobody is forcing you to use them. But don't assume that everyone wants to do things the same way as you. Don't try and prevent people from doing something different to you just because you personally don't like their choice. Regards James
Re: Feed Thread in Last Call
Sylvain Hellegouarch wrote: Can't you just ignore them then? The feed update / last-modified issue is not isolated to the use of thr:when and thr:count. As I mentioned in another note, you end up with the exact same problem when folks use the slash:comments element but no one seems to mind that. This problem is not unique to FTE, nor does FTE make the problem any worse. What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. Well to me there is no need to include, or specify, information that cannot be found otherwise already. The use case we've identified here is to be able to quickly display the comment count attribute on a web page where you have 10 entries. We really don't want to have to make 10 extra remote calls to retrieve 10 integers when they are so easily included in the top level entry feed; in fact, should a standard require this, we'd have to shrug and embed the data inside proprietary extensions for performance reasons. Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added = 304 Not Modified B. A comment added = I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. - Sylvain -- John Panzer System Architect, AOL http://abstractioneer.org
Re: Feed Thread in Last Call
If you don't like these attributes, that's fine - nobody is forcing you to use them. But don't assume that everyone wants to do things the same way as you. Don't try and prevent people from doing something different to you just because you personally don't like their choice. The problem I've raised is not about my taste in the end but about making sure we have taken every aspects into consideration. As you said, maybe there are other ways of doing than the basic algorithm I suggested but they do not play on the same level. Anyway, sorry if I came harsh on this question. I didn't mean it but saying that I don't have to use it if I don't like it is not really relevant. We re not discussing what each of us would do but what we want the community to be able to do. James Would you consider adding informative documentation on this matter in the spec or is that out of its boundaries? - Sylvain
Re: Feed Thread in Last Call
This boils down to an implementation choice. The thr attributes provide a way for UI's to display something before fetching the feed, which is often useful for an individual to decide whether or not it is even worthwhile to fetch to the comments feed in the first place. Also, consider that comment feeds may span multiple pages (using the paging link rels). With your algorithm (which, yes, is the only authoritative way of determining *exactly* how many comments have been received), you would have to retrieve every page and count up the comments. Considering also that feeds do not necessarily have to be ordered chronologically (tho most are) and that the feed may contain comments to multiple entries, getting a precise count of the total number of comments can be a time and resource consuming process that involves examining every individual entry in the feed for the presence of a matching in-reply-to link. Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. Fair enough. It sounds reasonable but I'm still not fully convinced. I'm happy we discussed it anyway. Thanks, - Sylvain
RE: Feed Thread in Last Call
Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. This to me is what its all about. I hear a lot of people saying that you can't be sure that the comment count is accurate. That the ONLY way to be sure is to get the whole feed with all the comments. To those people I would say you have trust issues. I am being snide, I admit, but truthfully, why would Six Apart (or any other implementer) not want to keep the two values in sync when it is so clear that we SHOULD. Certainly my implementations do. And if they were ever out of sync (i.e. the count attribute saying 5, and the feed containing 6) then that is a bug and I frick'n need to fix that. Byrne
Re: Feed Thread in Last Call
* James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]: The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. Supply per-link information as namespaced attributes on link elements, if you must. I don’t like the idea, but it seems there is unfortunately no way to associate link-specific RFC 4287 Simple or Structured Extension Elements with a link. (But why `thr:when` rather than `thr:updated`?) However, don’t neglect to provide a way to supply a global reply count. That would break the argument that the FTE covers nearly every threading use cases without having to resort to a gaggle of other extensions and hence weaken FTE’s position, IMO. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: Very simple reasons: the attributes are easier to implement, Speaking as an actual, rather than alleged, client implementer, I find this assertion ridiculous and dishonest. are allowed by RFC4287 and are being used in real deployments. So, the argument is that it's already deployed, then? It looks like you agree with me. -- Robert Sayre
Re: Feed Thread in Last Call
A. Pagaltzis wrote: * James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]: The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. Supply per-link information as namespaced attributes on link elements, if you must. I don’t like the idea, but it seems there is unfortunately no way to associate link-specific RFC 4287 Simple or Structured Extension Elements with a link. (But why `thr:when` rather than `thr:updated`?) RFC4287 does not forbid simple or structured extension elements on link. However, don’t neglect to provide a way to supply a global reply count. That would break the argument that the FTE covers nearly every threading use cases without having to resort to a gaggle of other extensions and hence weaken FTE’s position, IMO. I will consider adding a thr:count element to the spec to cover the global count case. - James
Re: Feed Thread in Last Call
At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. In the IETF, individuals can submit documents to become RFCs without those documents being Working Group items. This document (and all of the other format extension documents out there) fall into that category. If the author asks an Area Director to have the document published as a standards-track RFC, the AD will most likely ask for input on any relevant mailing list, including any existing WG mailing lists. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre
Re: Feed Thread in Last Call
Robert Sayre wrote: [snip] Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. ...explicitly designed to break a very popular implementation!? Give me a break. I've been purposefully judicious lately not to respond to crap like this but given the Last Call status on the spec, I think several very clear points need to be made: 1. My decision to use the attributes has absolutely nothing to do with Microsoft's implementation. In fact, the attributes were introduced to the spec *before* I knew any details about the Microsoft implementation. Any claims to the contrary are false. Any claims that I *explicitly designed* the extension to break a particular vendor implementation borders on the downright absurd. 2. Microsoft's implementation is no more broken by the use of the attributes than any other feed reader implementation that has not been specifically modified to support the extensions. I use Liferea, it can't do anything with the thr:count or thr:when attributes either. I guess that means I exlicitly designed the spec to break Liferea as well? Microsoft's implementation doesn't support multiple enclosures, so I guess RFC4287 was explicitly designed to break their implementation? Please, enough. I asked Byrne Reese if he could load up Sam Ruby's personal blog feed in IE7 and capture a screenshot. Sam's feed uses the thr:count and thr:when attributes. IE7 worked as expected, properly ignoring the extensions it does not understand. http://www.snellspace.com/public/ie7screen.png What's broken? - James
Re: Feed Thread in Last Call
On 5/17/06, James M Snell [EMAIL PROTECTED] wrote: What's broken? Do you think the AD and this WG are dumb? Why are you setting up such an obvious strawman? Congratulations, your extension didn't break Atom. The point is that your extension is broken. You're including attributes in that document that you know won't be visible to a large number of implementations. You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. -- Robert Sayre
Re: Feed Thread in Last Call
* Robert Sayre [EMAIL PROTECTED] [2006-05-17 01:50]: You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. I suggested an approach based on cross-referencing with the `href` value, but interactions with xml:base invalidate that approach. Other than `href`, there is no other hook on `atom:link` which could be used for cross-referencing without resorting to microparsing hacks. The root of the problem is a miniscule omission in RFC 4287: Sec 6.4. does not list `atom:link` as a location for Metadata elements. It should have. The effect is that links in Atom can only be extended at the XML level, not at the model level. There is no other reasonable choice for the FTE than to supply this information as namespaced attributes on the link element. This is now clear. I hate the idea as much as you do, but RFC 4287 is what it is. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. That doesn’t mean there is *no* reason for any of these technical decisions. But I agree that James has advocated the position he chose on this particular issue extremely poorly, just as you’d have done your own argument a favour by omitting your interpretation of the matter as vendor politics. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
On 5/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. Sure there is, and it's the way James did it. Is the information valuable? Does the spec cover cardinality issues? Is the link element useful here? Was the spec less effective in its previous incarnation? The answer to all of these questions is no. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
On 5/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote: - We're talking about visibility to implementations of the base spec only, not implementations of the extension, naturally. Any new information can be visible to implementations of that extension. There's a misunderstanding here. Many applications rely on a feed parsing service provided by the OS or a language-level library. Some of those platforms (MS is not the only one) don't provide access to extension attributes on the link element. For example, entry ... foo:bar / link foo:bar=baz ... / /entry here the extension attribute stands a chance of getting lost. The reason this occurs is because it's much easier to design an API that doesn't deal with these things in the general case. This situation could change in the future, as Atom consumer APIs develop. My implementation will parse and preserve the attribute, but I'm not sure what I'm supposed to do with it at an application level, especially if I encounter more than one such link element. As a result, I see no reason to introduce gratuitous compatibility problems when the cardinality of the link element doesn't seem to suit the problem very well. - We're talking about adding machine-parsable data that would be invisible to readers of the post content I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. -- Robert Sayre
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I thought the working group was fairly clear about the dubious value and placement of these attributes, and you yourself posted that no one was implementing them, they were strictly informational, and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. now is the time to step up and make your case. You've merely stated you believe that moving these attributes back to the original location is the right decision. That is not a technical rationale. I would expect to see a more compelling reason, given the clear, technical rationales of those against your decision. On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. -- Robert Sayre
Re: Feed Thread in Last Call
* Robert Sayre [EMAIL PROTECTED] [2006-05-16 04:45]: […] +1 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I thought the working group was fairly clear about the dubious value A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. None of the folks I know of that have actually implemented support for the extension has had any problems with them. and placement of these attributes, and you yourself posted that no one was implementing them, they were strictly informational, and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. I never posted that no one was implementing the attributes. Quite on the contrary, you can pull up quite a few TypePad and Friendster feeds that are using them. You can also look at Sam Ruby's personal blog... or look at my wordpress and roller blog feeds. The attributes are being used. What I did say was that I wasn't aware of anyone using multiple replies links in a single entry and that I personally did not intend on publishing any feeds that used multiple replies links in a single entry. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. The interaction is unspecified because there is no interaction. As I've said before, the thr:count and thr:when attributes apply only to the atom:link element to which they belong. The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. The roles of the attributes are clearly specified in the spec. There are existing feeds in deployment that demonstrate their use. . On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. My apologies, I thought I had already done so. It will be fixed in the next revision. - James
Re: Feed Thread in Last Call
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. None of the folks I know of that have actually implemented support for the extension has had any problems with them. I find your answers most unsatisfying and full of circular reasoning that serves mostly to dance around the fact that you and a few others have already deployed. That's been your argument for months now, and the IETF process has a way to deal with that situation: Informational. -- Robert Sayre
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/16/06, James M Snell [EMAIL PROTECTED] wrote: A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. Very simple reasons: the attributes are easier to implement, are allowed by RFC4287 and are being used in real deployments. That's more than enough justification for me. I agreed in principle with the arguments presented by David and Aristotle; Accordingly, I drafted up an alternative; Implemented the alternative; Compared the two implementations and the pros/cons of each; Discussed those on the mailing list; and decided in the end that the risk/benefit weighed in favor of the attributes. After testing a number of Atom implementations, I have yet to find one that is broken as a result of using the attributes. - James
