Hi everyone,
I was reading the Atom Feed Thread draft [1] yesterday and I ran into a
problem as I described in my blog [2]. To recap the 'in-reply-to'
element defined in that specification takes an 'id' attribute that
specifies /the universally unique identifier of the resource being
Hello Thomas,
It could lead to confusion, but as Atom doesn't define such an
attribute in its own namespace (or on elements in its own namespace)
and as no other extension that I know of do that either, I don't think
it really matters…
You are right Atom does not define such an attribute
Considering the above-mentioned symmetry with @href, I’m coming
around to whose-ever view it was that this attribute should be
called @ref for balance.
+1 for @ref as well.
Seriously though, the atom:name element is described as a
human-readable name,
Do you mean that human-readable is equivalent to solely English?
Because as a French, having accents in names is so natural that I see it
as human readable too ;)
- Sylvain
Just wanted to follow through on this for everyone. Given that there
are vendors getting ready to ship code based on the current rev of the
spec, I'm *not* going to rename the id attribute to ref. Yes, I
know that id is confusing to some folks, but we're just talking the
name of a single
Hello James,
So, with that, let me go ahead and open it up to a vote with the caveat
that votes from folks with concrete plans to implement the spec will
carry more weight so I'd appreciate a heads up.
1. Do I change in-reply-to id=... / to in-reply-to ref=... / ?
and.. to address David's
Type seems a bit vague, this seems to be mainly about describing how
an entry should be processed. A few possible ways to do that:
a) Using categories and a known categorisation scheme
b) Using an ex:processAs extension
c) Using domain specific extensions, eg contact:VCard /
d)
Hi everyone,
These days It seems that when UAs request a server to check if a feed has
changed the server responds with either an HTTP 304 Not Modified status
code or by returning the updated feed.
It looks to me as a problem if only one or a couple of entries have been
updated within the feed
Hi Dave,
Check out A-IM: feed [1]. It is already implemented by lots of
aggregators, and it is trivial for client implementors to support.
[1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html
Very nice article indeed and it shows I'm not the only wondering about
this. The A-IM
[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
http://blogs.msdn.com/rssteam/archive/2006/04/08/571509.aspx you'll find:
Very nice article David, I really like the safe approach taken by
Microsoft on this one.
Thanks,
- Sylvain
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
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
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
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
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
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
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
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
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
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
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
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
And I am sorry for the numerous mistakes I make in my written English. *sigh*
James M Snell wrote:
Just an FYI,
http://wiki.apache.org/incubator/AriProposal
http://www.snellspace.com/wp/?p=323
http://www.snellspace.com/public/ari.tar.gz
We are proposing the creation of an Atom Reference Implementation
project at Apache and have donated source to kick things off.
Demokritos might be quite well advanced but unfortunately Python code
is not very suited for us poor souls who still have to struggle with
java environments ;-)
I guess I kind of got that as well. That being said, it will be nice of
the project at some point can state exactly how it will
The goal is a reference implementation. The goal is to be exactly correct.
Being in a particular language, or even being fast enough to be usable,
is beside the point. In particular, a reference implementation should
always choose code readability over speed.
Fair enough.
If the goal is
I believe Jigsaw [1] is a an example of what you mean.
Jigsaw: http://www.w3.org/Jigsaw/
But you all knew that. ;)
- Sylvain
That sounds good to me.
Please not though that I didn't care about the language, my only
questions were:
1. Why not using an existing project?
2. How interoperable had you planned to be?
It seems these questions have more or less been answered so I'm fine :)
- Sylvain
Right. IETF specs
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
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
Definite +1
+1 as well.
I think most of the use cases for paging have to do with things like
GData, OpenSearch, etc -- i.e., query results. That sort of thing
isn't targetted at desktop aggregators AFAICT; it seems to be more for
machine-machine communication, or for browsing a result set.
Which sets the
You can have two entries or feeds with the same id, as long as they
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all the same properties...
/me wonders
Nice work Peter. Very nice.
Peter Saint-Andre a écrit :
FYI...
Original Message
Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt
Date: Mon, 26 Jun 2006 18:50:01 -0400
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: i-d-announce@ietf.org
A New
On 6/27/06, James M Snell [EMAIL PROTECTED] wrote:
Please define conformance in regards to this test. That is, what is
the exact behavior that a library must perform when a code library has
an API like, getContent on the content element.
e.g., is a parser not conformant if it passes the
Hey Sylvain,
On this one, I'm being very serious. I need to know what conformance
means. Hiding the div completely from users of Abdera would mean
potentially losing important data (e.g. the div may contain an xml:lang
or xml:base) or forcing me to perform additional processing (pushing
Hi all,
I have updated atomixlib [1] in order to support the Feed Thread Extension.
atomixlib is a Python package to simplify the generation of Atom
documents. It offers two underlying engine, one using Amara [2] and the
other one using ElementTree [3]. atomixlib does not try to ensure the
Although I share Robert's concerns about how this spec became a Proposed
Standard, I really have trouble to see the issue here. As a matter of
fact, I'm using a purl.org URL in one of my (non-Atom related) drafts as
well.
What we're talking about here is not change control over the
This took me quite a while to think through, but in the end I
agree. Translations of a resource will often have slightly different
contents in terms of the semantics of what is said, so I'd give them
different ids.
True. If you buy a book in English and then the translation of that book
in
2006/7/27, Sylvain Hellegouarch:
This took me quite a while to think through, but in the end I
agree. Translations of a resource will often have slightly different
contents in terms of the semantics of what is said, so I'd give them
different ids.
True. If you buy a book in English
FYI
http://www.defuze.org/archives/2006/08/19/atomixlib-egg
- Sylvain
FYI... The Atom Threading Extensions are now RFC 4685.
- James
Congrats James for this extension :D
- Sylvain
All,
A while ago I had presented atomixlib and amplee, two Python packages to
handle teh Atom format and the Atom Pub. protocol.
For over a week now I've worked really hard to upgrade both those
packages to make them much more useful.
atomixlib helps the generation, serialization and
My assumption: a client cannot create a media resource without also
creating a media link entry. When I POST a media resource to a
collection, a media link entry is *always* created.
Same here. Lisa what do you mean by creating a media resource manually?
If you do not use an APP service to
Hi folks,
Quick question regarding the atom:author element in a member resource.
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author (which could be considered as not valid but that's not
the question here), now say that my app server does not have any
Tim Bray wrote:
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the post
with an error message. It's hard for me to see
James M Snell wrote:
-1. The current spec is fine as is. It currently does not say anything
about whether or not the post entry MUST be valid although that is,
indeed the spirit of the spec. The spec does not say that servers MUST
reject entries that are not valid. Servers are free to
Well I share the concern because while developing amplee I ran into
issues like that. My conclusion was to apply HTTP error handling where I
could and where it made sense and leave the rest to the application
developer using amplee.
For instance return one of the 4xx error code when I meeting
Robert Sayre wrote:
Edward O'Connor wrote:
I am worried that there are three simultaneous efforts to spec out feed
autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
this stuff would get specced just once. WHAT WG seems like a neutral
ground, syndication-format wise,
Robert Sayre wrote:
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
3. We define a new media type for Atom Entry Documents,
e.g. application/atomentry+xml
No one relies on Atom Entry alternates now, so this is the best
option. We should tack it onto the APP draft, since that will
Jan Algermissen wrote:
Hi James,
On Nov 29, 2006, at 5:16 PM, James M Snell wrote:
== Status ==
Proposed
== Rationale ==
The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.
I took that to
Mark Baker wrote:
Interesting, thanks. But serving different purposes doesn't
necessitate a new media type. What's important is how the two types
of documents are interpreted.
How does your processing of an entry document differ from the
processing of a feed containing (only) that same
Daniel E. Renfer wrote:
The difference between a collection of entries and a single entry is
an important one. Sure, once you get inside the Entry, everything is
the same, but knowing ahead of time that you are requesting a single
Entry assists in processing. If I'm getting an
Mark Baker wrote:
I'd be happy to believe you James, if I could find where in the spec
that was stated.
Neither does it state they are a 1-to-1 relationship.
If it looks like an alias, and acts like an alias ... 8-)
Calling them aliases won't make them necessarily aliases.
I find
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote:
Mark Baker wrote:
[snip]
Ok, but I don't see that this would necessitate a new media type.
It's just an entry without a feed. You'd use the same code path to
process that entry whether it were found in an entry or feed document,
Jan Algermissen wrote:
On Dec 6, 2006, at 11:44 PM, James M Snell wrote:
I certainly hope you're kidding about dropping entry docs.
Sure, yes. But your wording IMHO seemed to imply that what feed readers
do should guide a decision. So, given they are not interested in the
entries,
Bob Wyman wrote:
On 12/10/06, Eric Scheid [EMAIL PROTECTED] wrote:
The only danger [of defining a new media type] is if someone has
implemented
APP per the moving target which is Draft-[n++] ... they should
revise their test implementations as the draft updates, and certainly
update once it
Consider GData apps. Their docs aren't clear (tsk, tsk!) about the
use of a media type when inserting entries[1], but if they're doing it
properly then their services should be keying off of
application/atom+xml, and so will break if that's changed.
And? Should a status quo be better on
Other server implementations should have the same issue, of course.
So please explain me what a server currently does upon receiving an Atom
feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?
Returning a 415 error code seems like the wrong option since the
James M Snell wrote:
Sylvain Hellegouarch wrote:
[snip]
The GData server implementation requires a Content-Type value of
application/atom+xml when POSTing or PUTting an Atom entry to a
collection
(for all non-media collections). It will respond with a 400 (Bad Request)
http error
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter
Can a client modify an entry to contain a link relation element in the
following cases:
- To point to a resource on a different server entirely?
There is no reason to believe that any of these resource are on
the same machine to begin with. I could POST to media to machine A
and have the
I believe I first saw this in a response made by Roy Fielding to an
assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I
can't immediately find the reference.
Could it be?
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0228.html
- Sylvain
Eric Scheid wrote:
On 15/12/06 7:29 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Besides, if you want to do fancy thing with a member, simply post a
media resource which is an atom entry. This won't be modified by the
server and will solely be treated a media resource.
promise? does
Hi folks,
Wth the first version of the type parameter draft [1] recently released
by James, I was wondering if implementors had started implementing it
either in their Atom consumer or APP server/client?
Or is it to be considered too soon?
- Sylvain
[1]
Hugh Winkler wrote:
The draft makes no mention of file extensions.
Atom Feed and Entry Documents can have different processing models
and there are situations where they need to be differentiated.
It would be good to enumerate some of those situations, and to examine
whether processing
Becker, Matthew R wrote:
Given a feed of discussion board topics, how do you show that an Atom
entry representing a topic has a related child feed representing the
posts for that topic? I was looking at the rel attribute of the link
element and I do not see a valid value of child. I thought
It seems that:
http://atompub.org/rfc4287.html
doesn't work anymore. Anyone feeling like fixing it?
- Sylvain
Lionel [Over-Blog] wrote:
Hello,
I am new to this list, this is a short introduction about me and why I
am interested in Atom.
I am working for a French company editing the most visited blogs
platform (6M pages/day, 600K blogs).
We are implementing Atom Publishing Protocol to give our
Erwan Loisant wrote:
On Fri, 2007-03-09 at 13:12 -0700, Brendan Taylor wrote:
I'd like to represent bookmarks using Atom, so that I can manipulate
them using the Publishing Protocol.
I'm not sure whether they're doing it the right way or not, but
blogmarks.net is APP to manipulate
71 matches
Mail list logo
