Feed Thread Question: Identifying Comment Feeds
James & Company: Is there any chance of seeing something added to the spec that could identify a feed or entry as a subordinate comment, rather than simply a reply? Here are the situations I'm facing during test implementation... Entry A is a blog posting, Entry B is a comment posted in response to Entry A, and Entry C is a third-party blog posting that claims to be a reply to Entry A. (1) I consume Entry A, and then Entry B. I note Entry B's in-reply-to id/ref, see that it matches Entry A, and thread the two together. All is well. (2) I consume Entry A, and then Entry C. I note Entry C's in-reply-to id/ref, see that it matches Entry A, and thread the two together. All is well. (3) I consume Entry C, and then Entry A. Since Entry A did not yet exist when I processed Entry C, I create new threads for both Entry C and Entry A. All is (basically) well. Here's where we get into trouble... (4) I consume Entry B, and then Entry A. Since Entry A did not yet exist when I processed Entry B, I create new threads for both of them. Unfortunately, Entry B was never meant to stand alone in any real sense, unlike Entry C. If Entry B had a way to clearly convey that it needs Entry A to make any sense, I could just ignore it until Entry A shows up. Absent such a mechanism, I can't ignore anything, because for all I know, Entry B is just like Entry C. I guess what I'm looking for is an @isrealparent attribute on in-reply-to. (Bad name, I know.) Just something that allows the replying entry to assert a closer relationship to the other resource. -- Roger Benningfield
Re: Atom Comments Extension
> I believe that's because they're not necessarily expected to be derived > from Atom Entry IDs. Agreed. I've been making experimental use of the extension with RSS, and will continue to do so... no Atom IDs in sight. -- Roger Benningfield
Re: The benefits of "Lists are Entries" rather than "Lists are Feeds"
> What is wrong with my > suggestion that lists-are-entries is much more useful than the alternative? Bob: Well, off the top of my head... (1) If the lists are embedded as (X)HTML, then only aggregators that display markup will be able to do anything with them, and headline-only aggregators will be useless. (2) If the lists are embedded in a new extension of some sort, developers have to buy in to get even minimal functionality. Not so if the entries are list items... even a non-list-aware aggregator will be able to display *something*. (3) If the lists are embedded as (X)HTML, my options for re-sorting the list are somewhere between minimal and non-existent. In fact, the only benefit I can see (as a user) to lists-within-entries is the ability to easily archive the state of the list. But that's probably better left to aggregator developers to implement as a feature. -- Roger Benningfield
Re: Don't Aggregrate Me
> Remember, PubSub never does > anything that a desktop client doesn't do. Bob: What about FeedMesh? If I ping blo.gs, they pass that ping along to you, and PubSub fetches my feed, then PubSub is doing something a desktop client doesn't do. It's following a link found in one place and retrieving/indexing/polling a document somewhere else... sounds distinctly spidery to me. But honestly, I'm not interested in nit-picking anyone's definition of "robot". To me, it's a matter of being friendly to the people providing all that content... if they make a point of telling me to stay away, I'm going to stay away. Let's say I'm absolutely convinced that my republishing aggregator isn't a spider, for whatever reason. Fine, I'm going to ignore any "*" directives in robots.txt. But I'm not going to ignore the file entirely, because if someone goes to the trouble to add an entry specifically for me, then that's a hint-and-a-half that I need to leave him alone. We've got a mechanism that allows any user with his own domain and a text editor to tell us whether or not he wants us messing with his stuff. I think it's foolish to ignore that. -- Roger Benningfield
Re: Don't Aggregrate Me
Bob: It's one thing to ignore a wildcard rule in robots.txt. I don't think its a good idea, but I can at least see a valid argument for it. However, if I put something like: User-agent: PubSub Disallow: / ...in my robots.txt and you ignore it, then you very much belong on the Bad List. -- Roger Benningfield
Re: Don't Aggregrate Me
> Mhh. I have not looked into this. But is not every desktop aggregator > a robot? Henry: Depends on who you ask. (See the Newsmonster debates from a couple years ago.) Right now, I obey all wildcard and/or my-user-agent-specific directives I find in robots.txt. If I were writing a desktop app, I would ignore any wildcard directives, and obey the specific stuff.. -- Roger Benningfield http://admin.support.journurl.com/
Re: xml:base abuse
Sjoerd: While reading your linked post, I noticed this: "Finally I'd like to share a trick to set the base URI for escaped HTML in RSS and Atom: add a BASE element to the beginning of the HTML content." Maybe I shouldn't be, but I'd be surprised if that worked in too many aggregators. After all the warnings (and platypus attacks) over the years, I know that I strip pretty much any non-essential markup/attributes from incoming RSS/Atom items, including html:base. -- Roger Benningfield
Re: More about Extensions
Dave: I think I see what you're getting at... correct me if I'm wrong. So I decide that my aggregator is going to look for unknown Simple Extensions in Atom feeds and display them as a table of name/value pairs at the bottom of every entry. And during the display process, I'm going to run a regex over the values and linkify any URLs I find. When someone's relative references just sit there as plain text and I get a complaint, who's to blame? (1) Me, for trying to provide generic support for unknown extensions? (2) The publisher, for failing to consider non-specific or limited support of the extension? (3) The complaining user, for expecting too much? If it's (3), then I agree with Tim... the spec says what it says, and that's fine. Otherwise, there may be a legitimate problem here. -- Roger Benningfield
Re: Introduction to The Atom Syndication Format
Sam: I've only given it a quick skim, but at first blush, I think it looks great. -- Roger Benningfield On 8/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > http://www.atomenabled.org/developers/syndication/ > > Feedback welcome. > > - Sam Ruby
Re: Atom 1.0 xml:base/URI funnies
On 7/17/05, Tim Bray <[EMAIL PROTECTED]> wrote: > I'm worried how XML-reader implementations will > do supporting all this base-URI stacking. If this kind of thing is > going to cause breakage, maybe it's not good practice. Tim: Oh, there's gonna be breakage. :D I know of at least a few hundred thousand XML parsers in production environments that don't know xml:base even exists, thus requiring all kinds of obnoxious hoop-jumping just to get a few geeky feeds to work... and that's without stacking. -- Roger Benningfield
Re: More while we're waiting discussion
James: Given that this kind of thing is pretty near-n-dear to me, I'm
quite interested. A couple observations and/or thoughts:
(1) I like this much, much better than the proposed ThreadsML mess of
years past. Simple is good.
(2) Implementation might be a hard sell, so don't get your hopes too
high. wfw:commentRss has been around for years, and RSS Bandit,
Newzcrawler, and (I think) Sharpreader are all on board. But since
more popular feed readers like NetNewsWire and Feeddemon don't support
it, getting individual bloggers to care can be challenging. Which is
kinda silly, since WordPress does per-entry comment feeds out of the
box, but whatcha gonna do?
(3) The link @rel="in-reply-to" @href="{$original-entry/atom:id}"
construct makes sense to me. Particularly since it doesn't just
duplicate wfw:commentRss, which would be kinda pointless.
(4) RE: @rel="comments" vs. @rel="related"
I generally feel like more specific is more better, but I can see
arguments both ways.
--
Roger Benningfield
JournURL
Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)
> Can you tell me, in those "unusual cases" when there is "difficulty > in determining which instance came last," what the heck am I supposed to do > if the users expect to always see the "most recent" instance? Bob: The same thing you'd do if you had two entries with matching ids and modified dates. -- Roger Benningfield
Re: Refresher on Updated/Modified
> PaceDateModified2 deliberately doesn't prohibit this, nor does this > prevent the proposal from fulfilling its goal to provide a temporal > ordering for entry instances. Dave: I'm pretty much +0 on PDM2, as I've mentioned previously. Your modifications to the concept address my "this will break stuff" concerns with the original formulation, so I'm okay with however it works out. But I have a question, and I'm asking you specifically because you seem to be approaching your argument in a reasonable tone and fashion. My apologies if I'm pestering. Near as I can tell, folks have modification dates. In my case, that is a date that is updated every time the user clicks "save". In Tim's case, that is a date that he chooses. In other apps, that may be a date that matches when a new comment was added to a blog entry. Nothing in the spec is going to change these realities. And none of these approaches are *wrong*, or invalid. We each get to define "change" in our own apps, so we can approach atom:modified's MUST clause as we see fit. For all practical purposes, it doesn't matter whether folks use atom:updated or atom:modified. You're going to get the same date. With that in mind, what are the actual benefits of atom:modified over atom:updated? The end result will always be identical, unless I'm missing a crucial, well-hidden point. Please note that it has not escaped me that this cuts both ways. Why fight for atom:updated over atom:modified when it is beyond the scope of the Atom spec to define the nature of change in the universe? Hey, if Tim doesn't consider a typo a real modification, then it just isn't. Period. It's his writing, his app, and he defines the rules and the terms. The more I look at this, the more I see people fighting over phantoms. -- Roger Benningfield
Re: Refresher on Updated/Modified
> > change from a unicode combined char to single + combining > > diacritic, > > No. > > > change in paragraph 27 of an article that doesn't show up in a > > summaries-only feed, > > No. Dave: In my case, and seemingly in the case of most of the tools surveyed, both of those would get a "yes". I suspect that in many cases, simply clicking "edit" on an entry and then immediately clicking "save" will cycle the modified date forward, even if zero changes were made. -- Roger Benningfield
Re: Non-empty elements
> Rephrasing slightly... + 1 -- Roger Benningfield
Re: Consensus call on last raft of issues
> RogerB specifically mentioned that TiVo users > squawked when he took away title-only feeds. Robert: Two things: (1) By "TiVo users", I was referring to the folks inhabiting TiVo's official message boards... my scraped, title-only feeds were better suited for a high-traffic forum than the native feeds produced by vBulletin or whatever they're using. So just to clarify, I was *not* referring to apps running on a TiVo box itself. The only non-hack RSS reader currently running on the TiVo platform just uses a proxy to access Bloglines, and therefore doesn't have any unique preference for or against summary-free feeds. (2) I support the notion of an Atom Processor. Tim's proposed language implies that dropping content-free entries on the floor is a failure to function correctly, which is misleading. Defining the distinction between "a thing that is looping over a series of XML entries to extract data" and "a thing that is displaying, manipulating, or otherwise making use of that data" would be useful. -- Roger Benningfield
Re: PaceAllowDuplicateIdsWithModified
Eric: My bad... I was looking at Ye Olde PaceDateModified, not PaceDateModified2. Template-based systems can't reliably produce a PaceDateModified, but PDM2 is a different story. Consider the -1 moved to +0. -- Roger Benningfield
Re: PaceAllowDuplicateIdsWithModified
> There was opposition to atom:modified because we couldn't see a need for it. > Now we have a need for it. Eric: That most definitely wasn't the core reason for opposition, to my recollection. It was opposed because it can't be reliably produced by existing systems, among other things. (See the wiki for a survey of tools and the dates they support.) A big -1 for any pace that depends upon a mandatory atom:modified. -- Roger Benningfield
Re: atom:updated vs entry inheritance?
> Gah! What is the true atom:updated for the following entry? Eric: The entry-level version, IMO. -- Roger Benningfield
Re: PaceOptionalSummary
> Roger, please don't see this as an attack. Robert: I would have to be one seriously touchy prick to see that as an attack. Don't sweat it. > I don't think there's a scope argument here. That's what I get for using a loaded term. My apologies. Again, I think title-only feeds are reasonable. And in a letter-of-the-poorly-phrased-charter sense, they're definitely in scope. But from a broader "why are we bothering with this?" perspective, I think they're a bit off the map. If I create a minimal Atom feed containing a title/link/summary combo, I will get pretty uniform results across 95% of the aggregators out there. That's our baseline, the default expectation. If I create a minimal feed with just title and link, on the other hand, I'm going to get substantially different results from app to app. That's no sin, nor is it the end of the world. But it's the kind of thing that publishers need to understand going in. Does that require a SHOULD in the spec? Perhaps not. Maybe it just needs a big, bold paragraph in an implementation guide. But it feels like a SHOULD to me. Every title-only feed is a support request waiting to happen, as new users stare at their screens and wonder why the feed is "broken". And I'm not convinced that aggregator developers should be the primary heat-takers in such situations... if you're producing titles-only feeds, you need to know what you're doing, and you need to be educating users prior to subscription. For what it's worth, no one needs to feel compelled to address this post. I'm not trying to hold up the process. I'm just not sure I've adequately explained my thinking up to now, and wanted to give it another shot. The end. -- Roger Benningfield
Re: PaceOptionalSummary
> I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. -- Roger Benningfield
Re: the "atom:copyright" element
> A "rights" description might talk about trademarks, registered > trademarks, service marks, and so forth: different from copyright. Robin: In my opinion, the only place an atom:copyright should appear is at the feed level, as an assertion of ownership of the feed document itself. Rights statements relating to individual entries should live within the content, particularly references to trademarks and the like. So I guess I'm -1 on atom:rights. -- Roger Benningfield
Re: PaceTextShouldBeProvided vs PaceOptionalSummary
> Yes. If that SHOULD goes through, it becomes OK to write an Atom > Processor that catches fire when summary and content are both absent. Robert: Nothing about either pace will make it "not OK" to drop content- and summary-free entries on the floor, or come to a full stop when they're encountered. Such feeds would be completely useless in some apps, and therefore deserve to be tossed. PaceOptionalSummary simply enables an infinite loop of "talk to the other guy about that" responses to user questions, while PaceTextShouldBeProvided says that the tie goes to the aggregator. Kinda funny when you look at it that way, given the heated discussion on the subject. They could both be rolled into a single PaceWhoYouGonnaBlame and save everyone unnecessary reading. -- Roger Benningfield
Re: PaceAllowDuplicateIDs
> I have no good answer to that until I know what what an id stands for. > The answer "an entry" isn't sufficient. Bill: Semi-random thoughts... * An atom:id is a globally unique name for a specific database query. * There is no "stream of instances over time". There's just old data that's out of sync with that query. * If duplicate ids are allowed, the world won't come to an end. I'm almost sure. I think. -- Roger Benningfield
Re: Autodiscovery
> The problem is fortunately mitigated because user agents usually
> only offer copying @href ("copy link location").> I'm under the
> impression that they do something similar with rich-text copying.
Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's
XFN-friendly links page and paste it into my WYSIWYG editor, I get all
of his @rel="whatevers" in my post. This is the same behavior I've
noted in every IE- and Mozilla-based WYSIWYG editor I've tried.
--
Roger Benningfield
Re: Autodiscovery in as well as
> Is there something wrong with the HTML parsers? Nikolas: Are they installed by default on most servers? If not, can those running in sandboxes install them? >From the perspective of my niche, I can tell you that Coldfusion can use jTidy to make sense of random HTML, but it is (a) installed in virtually zero CF hosting environments, and (b) cannot normally be added by an individual developer working in a sandbox. (It's also riddled with bugs, but I'm just grateful to have it at all... I steer clear of gift horses' mouths whenever possible.) -- Roger Benningfield
Re: Autodiscovery
> how is a feed of recent entries a "substitute version for the document in > which the link occurs" when that document is some blog post long since > dropped out of the feed? Eric: A devil's advocacy moment... if I change the published date for the document to today's date, it will suddenly spring forward into my feed of recent entries. And at some point in the past, it was already in that feed. -- Roger Benningfield
Re: Atom feed refresh rates
> This is a myth perpetuated by cheapskate bloggers. There's no > technical reason for it beyond "I bought a lousy hosting package". Graham: I disagree. In a time where referrer and trackback spam agents are hammering servers everywhere, it's quite reasonable for aggregator developers to exhibit restraint and not add to the burden that the blogosphere has unintentionally created. That's not to say that there's something necessarily wrong with an aggregator that allows users to pull feeds every five minutes. If you're building something for people who are going to be subscribing to Gmail feeds or referrer logs (I'm subscribed to both in Newzcrawler), then you have to cater to those needs. The most anyone can ask is that you provide reasonable defaults and leave it at that. But I've got my own code set to limit refreshes to an hour or more, and don't forsee changing it. It's the right thing for *me* to do. -- Roger Benningfield
Re: PaceOptionalSummary
> That's fine, but we're not here to tailor the format to your app. Robert: Seriously, dude. C'mon. I don't care what little slap-fight you want to have with Sam, or Graham, or whoever else you figure is wronging the sublime rightness of your position. That's your thing, and welcome to it. You're not the first one to feel like "consensus" led Atom somewhere it had no business going. If you want to sit around and bitch about it, I'll might even join in. I was most unhappy with how things went in the XML-RPC vs. REST debate, for example. I've moved on, but I can at least sympathize. But you asked a question, and I answered it. Honestly, straightforwardly, and without an weasel-words. I did not ask anyone to tailor anything to anything. Try that silly crap with others if you must, but spare me. > I've > gotten feedback from embedded device developers complaining that XHTML > requires them to do more parsing than their app can handle, for little > practical benefit (for them). Note that we're also giving them the > short end of the stick with this requirement. If their embedded devices can't easily produce XHTML, then they don't have to do so. If their devices can't easily consume XHTML, they can either strip it or drop it. Again, the one thing Atom actually brings to the table over RSS is that content is clearly flagged. So where's the problem? (Or did someone slip something into 08 that says summaries must be XHTML?) > This is the assertion I have a problem with, and the opinions > expressed by others echo my gripe. Which part is the assertion that's causing you trouble? 'Cause half is in the charter, and the other half is one of those obvious things that Paul referenced. > Well, now we're just back to the sorts of feeds that are supposedly > perfectly ok on the condition that they contain an empty summary > element. Again, I support a SHOULD on summary. Not just adding an empty element... allowing publishers to drop it entirely, as long as they're aware they're doing something that will have an impact on the primary functionality of feed-consuming applications. Not that I think SHOULD is a good idea in this case. I just don't see the point in arguing about it incessantly, and SHOULD covers most of the bases. -- Roger Benningfield
Re: PaceOptionalSummary
> Sorry, what was your point again? Eric: The point was that the *application* drops title- or content-free entries. It never inserts them into the database. They go poof. -- Roger Benningfield
Re: PaceOptionalSummary
> Do you have an example? Robert: I'm an example. I also drop title-free feeds (see Scripting News)... given the nature of the app, a feed without titles or content is just worthless. That doesn't mean I have anything against content-free feeds for specific applications. After all, as you pointed out, I produce some. In fact, that's why I'm pro-SHOULD in this case; a weblog or wiki feed (Atom's two primary targets) should contain some form of content. But if you know what you're doing, and have no other choice, then drop it and cross your fingers. > What are the interoperability considerations that must be carefully > weighed? Apps that expect content won't get any. I haven't checked things out in a while, but once upon a time, Newsgator-in-Outlook would use the item's link as the content for a content-free feed. Newzcrawler, meanwhile, automatically forwards the user (via the integrated browser) to the link. And as I've already mentioned, I'll drop the items entirely. The publisher will therefore face unpredictable results relating to a key part of aggregator functionality... that's definitely worthy of a SHOULD. -- Roger Benningfield
Re: PaceOptionalSummary
> That's not good enough. You have to demonstrate an interop problem to > say SHOULD or MUST. Interop with *what*, Robert? What's the baseline? No aggregator *requires* a title... one can be synthesized. No aggregator *requires* an id... links, hashes, and so on do the job sufficiently for most purposes. No aggregator *requires* a date... if one's not attached, we can just slap on the date we acquired the entry. And so on... I honestly can't think of a single child of atom:entry that is required for interop. In which case, the only MUST in the spec would be "atom:entry MUST contain at least one child element of some kind. Have fun with that." No one needs Atom for producing a title-and-link feed. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. -- Roger Benningfield
Re: PaceOptionalSummary
> Do the following messages mean the same thing? Robert: In my app? Yep, exactly the same. -- Roger Benningfield
Re: PaceOptionalSummary
I'd be willing give a +1 to SHOULD language regarding summary/content. I'd prefer one or the other be required for a weblog-centric format like Atom, but I'll just do what I already do with title-only RSS feeds... have my code reject them as inadequate. -- Roger Benningfield
Re: NoIndex, again
> Most feeds do not contain atom:summary elements. It is optional. > This is not a useful path to a solution. Bob: The fact that a summary is optional is precisely why it is a useful approach. It's all about working together, taking responsibility, and operating in good faith. If a publisher provides a feed with nothing but inline atom:content, it's reasonable for me to assume that my web-based aggregator can display that content. If that publisher wants me to only display an excerpt, then it is reasonable to expect said publisher to insert an atom:summary into her feed. > In any case, reliance on > atom:summary elements wouldn't help you with RSS files. If Atom has a rights > issue then RSS does as well. There are two ways to approach the matter in RSS: (1) Rely on description/content:encoded as an analog to summary/content. (2) Evangelize the use of atom:summary within RSS. -- Roger Benningfield http://admin.support.journurl.com/
Re: PaceXmlContentWrapper
-1 for me. -- Roger Benningfield
Re: PaceCoConstraintsAreBad
> The few cases I have seen where there have been feeds which (briefly) > have not had so much as a summary, there always has been a swift and > clear response by the consuming public. Sam: In the case of the no-content feeds I've produced over the last few years, the response from the public has been "please keep them coming". The folks in the Tivocommunity forum want me to bring my scraped, title-only feeds back online because the recently added, native forum feeds are kinda useless. That said, I would have no problem at all with providing an empty content element in such a feed, and I'm sure most aggregators would handle it the same way they handle description-free RSS feeds. Of course, cruft doesn't scare me the way it does some folks. -- Roger Benningfield http://admin.support.journurl.com/
Re: PaceRepeatIdInDocument solution
> i) Syndication documents shouldn't ever contain multiple versions of > the same entry*. Graham: +1. > ii) Archive documents apparently need to be able to contain multiple > versions of the same entry. I don't even buy that much, personally. -- Roger Benningfield
Re: PaceXhtmlNamespaceDiv
> > > > That seems like a > good approach for those who do want the default namespace here. Julian: It might actually be the best compromise solution. Advanced developers will understand what's happening, and View-Sourcers can copy-n-paste that just as easily as they can copy-n-paste . The people left out in this scenario are intermediate developers... folks who know just enough to find such a construct confusing. I suspect Sam would prefer it if all three groups could get something they can grok, but if that proves impossible, the intermediate folks may be the ones we can politically afford to fluster. For what it's worth, I'm still +1 on requiring the . 'Cause personally, I figure if we're going to inconvenience anyone, it should be the most advanced among us. -- Roger Benningfield JournURL
Re: PaceXhtmlNamespaceDiv
I'm +1 when wearing my aggregator hat, and indifferent from a publishing perspective. -- Roger Benningfield JournURL
Re: Open Comments.....
> The problem with commenting as it is practiced today is that it > relies on granting others the right to write into one's blog. > ... > Thus, more and more commenting will move to a > track-back model (either explicit via mechanisms like > trackback or implicit > via link tracking tools like PubSub). Bob: Bah, bug, and hum. Comments are just micro-message boards, and message boards have been getting along just fine for many, many years without the help of PubSub or any other third party. More importantly, a reply that exists within the context of the source and a reply that exists in another space entirely are very different things... they're written differently, perceived differently, and often aim for different goals. That's not a problem to be solved. With that said, I don't think Atom needs to bake in anything fancy for comments. Personally, I'd be quite content if Joe tapped out a wfw:commentAtom and called it a day. -- Roger Benningfield JournURL
Re: PaceClarifyDateUpdated
> What do you propose one should do when the current system to which Atom > output is to be added do not record such updates but only records the > date when the bytes changed? Henri: As a practical matter? If that's what you have, that's what you use. But a lot of it comes down to knowing your audience and your priorities. If something on your box routinely tweaks your Last-Modified dates without making material changes, and you've got a lot of readers using aggregators that flag updated entries, you'll probably annoy some folks. You get to decide if that matters to you... if it does, turn off whatever is changing Last-Modified, or kludge together something to insert static dates into atom:updated. -- Roger Benningfield JournURL
Re: atom extensibility: Re: Don't mess with HeadInEntry!
> And even though many people seem to willing to create fill in language > for that part of the spec to make it seem like this part has been > addressed, your on the ground initial reaction is the correct one: > there is no well defined extension mechanism. Henry: I suspect that Bob's reaction would have been the same, no matter how well-defined the extension mechanism. Anything outside the core will have spotty (at best) support in aggregators and publishing tools. -- Roger Benningfield JournURL
Re: Entry order
> But if three are added, you can't order those three. Walter: I dunno... seems to me, if the publisher hasn't included atom:published info, then it's probably safe to assume that the order of those entries isn't important. -- Roger Benningfield JournURL
Re: Open Comments.....
> Any feedback on this guys? Curious to see what type of interest there is > here... Kevin: Why would anyone want to fiddle around with HTML classes to indicate comments when they can just publish/consume comment feeds? Or did I misinterpret the purpose of the effort? -- Roger Benningfield JournURL
Re: Entry order
> If clients are told to ignore the order, and given only an updated timestamp, > there is no way to show "most recent headlines"... At a single moment within a feedstream, sure... but the next time an entry is added to that feed, I'll have no problem letting the user know that this is new stuff. > Either we need a published date stamp or we need to honor the order. Maybe I've missed something amidst the chao-- enthusiastic array of Paces lately, but don't we *have* a published date? -- Roger Benningfield JournURL
Re: PaceXhtmlNamespaceDiv posted
> Of course things look differently if this issue affects more > platforms/parsers/toolkits. It does. I'm in a similar boat. On the other hand, since I'm going to be forced to parse Atom 0.3 until the end of time, and some 0.3 feeds don't use the div, it really doesn't make a difference to me. I'm gonna be looping over and xmlChildren array no matter what. Requiring the div could certainly make life easier for those who are going to restrict parsing to Atom 1.0, though. -- Roger Benningfield http://admin.support.journurl.com/
Re: PaceXhtmlNamespaceDiv posted
> Given that common practice is to include this element, making it > mandatory makes things clearer to both people who are producing > consuming tools based on the spec, and people who are producing new > feeds based on copy and paste. +1 -- Roger Benningfield
Re: Feed, know thyself?
Danny: Works for me, at least in the sense that I have no problem with it while wearing either of my blogging or aggregating hats. I would like to see some of the objections fleshed out a bit, though, just in case we're overlooking something significant. -- Roger Benningfield
Re: PaceMustUnderstandElement
> Are you saying that Atom 1.0 should not be extendable at all? Paul: Not at all. I'm simply saying that "must understand" gives influential publishers the power to force the hands of developers, something that RSS (wisely) doesn't provide. In addition, I have a philosophical objection, which I touched on briefly in my last message. Atom feeds should contain well-formed entries... if an entry requires non-core elements to make it minimally useful, I'd argue it isn't well-formed, and the use of Atom was ill-advised. -- Roger Benningfield
Re: PaceMustUnderstandElement
> But how likely is it that the problems will > outweigh the benefits? Antone: Extremely, in my opinion. A big -1 on this one. All it will take is an A-lister or three on a mission to essentially force every general-use client developer to support whatever pet extension they're fired up about that week, no matter how ill-conceived. And offering a user-controlled bypass isn't an option... I'm not ever gonna be in the mood to be sued by someone because my app allowed the user to turn off a feed's bundle of "must understand" DRM elements. If a publisher's data requires non-core elements to be minimally useful, then I'd say Atom is the wrong format for that data. -- Roger Benningfield
Re: PaceMustUnderstandElement
> the > cost must be kept very near zero. Tim: Agreed, although I'm not sure that's possible. Right now, if someone subscribes to a feed and gets nothing, I can say "Look, the publisher is producing ill-formed XML/invalid Atom/etc." and leave it at that. I've got a legitimate finger to point. But atom:must-understand drops my resources and design objectives directly into the hands of every A-lister in the blogosphere. They can effectively demand that I support whatever they want me to support. I sympathize with those who have harmless uses for this sort of thing, but I really don't want to face the inevitable Atomic soup nazis. Definite -1. -- Roger Benningfield
Re: PaceMinimalEntryVersioning
> I'm in favor of this--it's easy enough to imagine uses for it (like a > feed showing the history of a particular entry). Antone: I'm +0 about it, but it might be a good idea to include some pointed warnings for publishers. Some client apps are going to use the first entry in the feed, some the last... some will look at dates, some won't... and so on. As with many of these "someone might need it some day" proposals, multiple instances of an atom:id in a feed will mean the user experience goes from the standard "variable" to "wholly unpredictable". That means complaints sent to the client author, who then has the unenviable task of saying, "Look, the person who threw this feed together is following the spec, but so am I. Sucks to be you." Actually, I think I'll shut up now. The more I type, the closer I am to -1. -- Roger Benningfield.
Re: RSS extensibility
> I think this is a very nice example, and will show the power of seeing > atom as RDF. Henry: I hope it isn't too depressing to know that, at least for this individual, it really doesn't. To me, you've just sketched out a solution in search of a problem... there are far, far easier ways of getting the same results. Like, say, putting the geo and seismo data together in the entry to begin with. After all, absent a signing mechanism, merging two entries with the same atom:id is only going to get you in trouble. It'd be far simpler for the publisher of Feed A and Feed B to just do any merging on her own (she doesn't need a machine to deduce any relationships within her own data, after all) and produce a Feed C that saves everyone the trouble. > Should it merge these two entries or should it leave > them as separate? In my case, the later entry is ignored... existing entries are never updated once they're in the database. A different app would probably either (a) completely overwrite the old entry with the new one, or (b) declare them to be two distinct versions of the same entry. In any case, there's little pressing need to try and create a Frankenstein's Entry from the two. -- Roger Benningfield
Re: RSS extensibility
> Would you be satisfied with a paragraph that says that those who extend > Atom may do so by putting in namespaced elements, and that such > elements, when the information they contain is relevant to an entry, > SHOULD appear as a child of atom:entry? Tim: +1, for the sake of compromise if nothing else. Although y'know, having spent some time watching the podcasting crowd develop, I'm beginning to think such a clarification might even be necessary. I'm seeing folks wanting to shove all kinds of stuff into rss:item that actually has nothing to do with the conceptual item. Atom should probably head that impulse off at the pass. -- Roger Benningfield blog: http://admin.support.journurl.com/
Re: Posted PaceEnclosuresAndPix
> In > addition to being cumbersome, there is no good way to show that the > photos all go together. Ray: There are several, IMO. (1) Put them all in the same rss:category. (2) Use ENT and assign them all at least one common topic. (3) Put them in a distict feed. At least one of those is fairly trivial for just about every app out there, and all of them are better than treating a single item as a content dump, IMO. -- Roger Benningfield blog: http://admin.support.journurl.com/
Re: PaceCategoryRevised
> What good is a term without a scheme? And without a label either, all > you know is that something is from category #4. How is this useful? Graham: See del.icio.us. Someone's "apple" tag may relate to their career in fruit, while my "apple" tag may relate to computers... but in most cases, there's enough overlap for del.icio.us to do useful things. Same thing here. My "Flash" animation category may not really relate to the "Flash" category on an exhibitionist porn site, but I'm betting I'll get more good matches than bad over time. Particularly when dealing with the finite universe of my desktop aggregator. Naturally, folks with numeric IDs or whatever won't be able to cash in on random connections, but those are the folks who will be most likely to add @scheme and @label to their elements. -- Roger Benningfield
PaceCategoryRevised
> let's see if there is consensus on this Works for me. +1 -- Roger Benningfield blog: http://admin.support.journurl.com/
Re: PaceFeedState server-side proof-of-concept implementation
Mark: Here's another one. As you follow the state:prev elements backward, state:next elements will automatically appear to help you crawl back up. http://support.journurl.com/users/admin/?template=rss-full -- Roger On Wed, 24 Nov 2004 11:28:27 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > FYI, I've put 'this' and 'prev' elements on my RSS feed as a > proof-of-concept on the server side; see >http://www.mnot.net/blog/index.rdf > > This was done with templates only on stock Moveable Type 2.6. > > -- > Mark Nottingham http://www.mnot.net/ > >
Re: PaceFeedState
> Rather than presupposing what developers are going to > do, I'd rather get feedback from those people directly. Mark: FWIW, I've always had prev/next traversal enabled. This gets the latest entries in my blog: http://support.journurl.com/users/admin/ ...and this gets the five previous entries: http://support.journurl.com/users/admin/?month=11-01-2004&time=20:14:57 ...and this gets the five before that: http://support.journurl.com/users/admin/index.cfm?month=10-27-2004&time=15:32:52 So ignoring any broader implications, I don't have an immediate problem with the stuff you're describing. > If I publish a feed, I want my consumers to see the entire information > channel, not portions of it. That's a huge benefit. Not to those who only want their feed to serve as a source of update notifications. Of course, those folks are well-served by RSS, so maybe their usage isn't a big issue. -- Roger Benningfield blog: http://admin.support.journurl.com/
