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
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
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
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
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
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.
--
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
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
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
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
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
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
Rephrasing slightly...
+ 1
--
Roger Benningfield
Gah! What is the true atom:updated for the following entry?
Eric: The entry-level version, IMO.
--
Roger Benningfield
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
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
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.
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
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
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
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
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
Do the following messages mean the same thing?
Robert: In my app? Yep, exactly the same.
--
Roger Benningfield
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
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
I'm +1 when wearing my aggregator hat, and indifferent from a
publishing perspective.
--
Roger Benningfield
JournURL
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
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
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.
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
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.
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
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
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
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
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
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
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
38 matches
Mail list logo
