Re: Representing bookmarks
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 bookmarks; that may be worth checking it. http://dev.blogmarks.net/wiki/DeveloperDocs That's actually a very interesting link. Thanks. - Sylvain
Re: Introduction
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 users the ability to blog from outside our website (MS Office 2007, YouTube, Firefox extensions, etc...), and I am responsible for implementing this. Now that you know -nearly- everything about me, this is my first question : Is draft 12 of the APP expected to be the latest one before RFC acceptation ? Hi Lionel, Welcome. However you should subscribe at [EMAIL PROTECTED] instead since it is the right ML for APP. Regarding draft 12, it should be fairly close to be what the RFC will look like (if it gets accepted). BTW, which language will you be using for your implementation? - Sylvain
Broken link
It seems that: http://atompub.org/rfc4287.html doesn't work anymore. Anyone feeling like fixing it? - Sylvain
Re: Best practice for linking to child feeds
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 I saw this in an older draft. What is the recommended way to handle a hierarchy of related feeds? Thanks, Matt. Maybe RFC 4685? http://www.ietf.org/rfc/rfc4685.txt Alternatively I wonder if the Feed History spec. could suit you better: http://tools.ietf.org/wg/atompub/draft-nottingham-atompub-feed-history-08.txt - Sylvain
Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
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 software depending on file extensions also requires such differentiation. If ithe processing model is different enough to require distinction in the mime type, it's important enough to require distinction in the file system where mime types usually are forgotten. Server software responsible for inserting correct Content-type header can *possibly* set the correct value when serving a file, if the type=entry and type=feed documents have distinct file extensions. (I think this server behavior is an accident of implementation, because I've never encountered a mime type parameter in any mime.types file or in the Windows registry). Client software receiving a file similarly consults a mime types registry. I do not think any client software today would correctly be able to save the file with the correct file extension, because it would have had to have been programmed to parse all the parameters (including possible parameters to be defined in the future). If the client software has this entry in its registry: application/atom+xml; type=entry and receives a file with this header: Content-type: application/atom+xml; type=entry or this Content-type: application/atom+xml; gdatakind=event; type=entry there's little chance existing client software will assign the correct file extension to the saved file. On the other hand, if the draft assigned a new mime type to denote entries, all existing processing software on server and client side would correctly map content-type to file extension. Hugh Fair point but it has been extensively discussed in a previous thread and it appears that few people were keen on adding an entirely new media type. While the type parameter may not be ideal it seemed to be lest disruptive. I personally agree that a new media type would enforce the correct and native distinction between entry and feed but most people who have participated didn't feel like there was such a string requirement. - Sylvain
Type parameter implementation
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] http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt
Re: Atom Entry docs
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 option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode Personally, I would say that if we find the proper way to notify implementors they can't dismiss the type parameter then I'll +1 that option over the new media type. However we know that implementations won't make the effort to take it into account then what's the point over the current status? - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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 MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. Well, the spec doesn't require me to accept link relations which point to other servers. Finger-pointing rather than interoperability. I didn't quite understand your statement here. You make things more complicated than what Joe actually said. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic Forbidden error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. What did I do wrong? the client plaintively asks. A generic error code would mean there was an error in the first place. Why is this the case? Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. This is a fundamental change to what has been said over and over on this mailing-list. Allowing the client to have more power than the current draft allows on the Atom member would mean we have to detail all those cases within the draft itself and would strongly limit its simplicity IMO. 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. Then the client will have full control on it. The server must keep full control of the member resource. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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 the spec support this assertion? or is this another case of the server is in charge and can accept or change whatever it wants? e. No you are right, this is a gratuitous assertion here. However APP currently describes what a server is allowed to do on a member resource and not on the media resource. It could be interesting to see how extensions to APP could allow the server and the UA to agree on what level of modification each party is entitled to expect. - Sylvain
Re: Atom Entry docs
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 the long term? 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 media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? So I'm for James' option B) application/atom-entry+xml I'm -1 on that, but +1 on the type parameter. I'm still +1 on the new media-type and +0.5 on the parameter type option. - Sylvain
Re: Atom Entry docs
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 media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? AIUI, that's undefined, and will remain so no matter what is decided here. I don't understand what that has to do with a new media type breaking existing servers though. It has everything to do within the APP context in fact. We have only one mime type for two distinct semantics (well you disagree on that statement so I can understand why we disagree with the rest). Having a new media-type (or at least the type parameter) would help APP server implementors. Therefore the way servers would handle requests. Of course, APP isn't finished yet, and so technically we shouldn't be worrying about breaking implementations that jumped the gun. But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? We still disagree on this alternative you suggest I'm afraid. - Sylvain
Re: Atom Entry docs
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 on any other content type. It will also do the same if the request body contains an Atom feed document and not an Atom entry document. Right and I find that abusive of the mime type already. An UA that respects RFC 4287 and sends a feed to a collection that would state it accepts such media-type would not understand why it gets a 400 Bad Request (it's fairly interesting to point actually that because of that umbrella mime type you could not use the proper 415). Which is precisely why acceptentry/accept exists. Existing implementations already have to basically ignore the content-type and sniff the content. Implementations will have to continue to do so with the optional type param because it's optional. True but I've always found the entry awkward. - Sylvain
Re: PaceEntryMediatype
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 reaches RFC status, so no sympathies there. The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an aggregator to treat a single entry as the semantic equivelant of a single-entry feed. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. I have read your other message and I'm still nowhere near an understanding of it. In fine if you accept that an entry document is just equivalent to a single-entry-feed you have to detail precisely how this equivalence takes place and can be measured. Is it based on the atom:id? If yes is it on the atom:id of the entry or the feed? Is it based on its metadata? Again which ones since an entry embedded in a feed can overwrite the feed metadata. You should also explain why we have entry document at all if they are equivalent to single-entry-feed ones. Moreover you claim that it's going to break implementations. Which ones? How? Why? Can't those applications be updated? Why shouldn't APP be set straight because of those applications? There is a large feeling on the WG that there could be a use for distinction at the message level. We all acknowledge that could be disruptive but I don't think I can agree that it would bring down a all set of applications. You say those in favor haven't brought good use cases but neither have you. - Sylvain
Re: PaceEntryMediatype
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, dropping them is not too farfetched, is it? Let's just label 'em differently and move on. I still do not see the use cases justifying a new media type - it might be the right thing to do but for the time being it looks like a workaround. Considering you seem to only discuss their value from a feed reader point of view, I'm not surprised you don't see the use for at least minting the current media-type, let alone an entirely new one. I think at this stage having further discussion won't help anymore and I would like the WG-chairmans and editors to tell us what they think about this issue because we aren't going anywhere right now. - Sylvain Jan - James Jan Algermissen wrote: On Dec 6, 2006, at 11:30 PM, James M Snell wrote: Jan Algermissen wrote: [snip] So they should be fixed, should they not? They seem to only have implemented half a media type. The half they're interested in. Why aren't they interested in the other half? Ha! Forget about the media type - let's drop entry documents. Jan - James
Re: PaceEntryMediatype
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, right? Not necessarily. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. Isn't that just a case of people not implementing the whole spec though? FWIW, if that practice is widespread, then I think the group should consider deprecating entry documents. Minting a new media type won't help. Or, are there applications which only process entry documents and not feed documents? Mark. Mark, Since the beginning you seem to solely focus on what feed readers do or don't do. Suggesting deprecating the entry document on the APP list is quite missing the point really. If people keep seeing Atom as a RSS alternative then there is a big communication failure from the Atom folks. Atom feeds are actually less worthy than Atom entries which should have been pushed even harder as the first class citizen within the RFC. The Atom entry element is the one carrying the information and is the one that needs a media-type on its own, or at least a way to mint that media-type to make it clear to UAs what they're dealing with. In fact I will be really interested to hearing from folks who write APP client extensions for Firefox, Opera or else. Certainly they will tell us that they don't care about Atom feeds as much as they do about Atom entries. The thing is that adding a new media-type now would not impact thoroughly current implementations if for instance we were to say that application/atom+xml is for Atom feed and application/atomentry+xml was newly introduced for Atom entry. I actually do not understand why people get so reluctant at it. - Sylvain
Re: PaceEntryMediatype
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 unfortunate that RFC 4287 doesn't actually precise that particular point. We only have one media type and no clear definition of the distinction between an entry element and an entry document. So we have this discussion. - Sylvain
Re: PaceEntryMediatype
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 application/atom.entry+xml I know to use my stylesheet for only a single Entry, whereas when I'm getting an application/atom+xml resource, I know I have a collection containing 1 or more Entries. It's the difference between having a variable, or a list of variables. Imagine a system that uses conneg to give atom representations of a file system. I could request http://www.example.com/db/foo/ and depending on what I put in my accept could determine whether I'm getting back the collection of contents of foo/ or if I'm getting the information on the foo/ folder. There are times when you need to differentiate between the two types when rel= values are not available. I agree with James that there should also be a different rel= value to tell the UA what to do with it, but you still need that different type to signal the difference in what it actually is. Since most UA's out there don't really deal with single atom entries as it is right now, and most parsers will have to accept that they might get back only a single entry from an application/atom+xml and the ones that don't understand how to work with a single Entry will just ignore the application/atom.entry+xml link anyway, the impact isn't all that great to clear up this difference in semantics now and for good. Daniel E. Renfer http://kronkltd.net/ I wholeheartedly agree with you here. The problem is that so far most of the discussion has been carried from the client side of things without trying to understand the limit of the server side. There are cases where not having a specific media type (or at least a way within the media type to distinguish them) will be a problem. Maybe the impact of those issues is not worth the trouble but if application/atom+xml leads us to the same situation of the unusable application/xml media type then I predict quite mess. My issue here is that most of the discussion has been centered around how an Atom document was consumed until now. With the versatility of Atom and the power of APP it is more than likely that new use of those formats will show up. They may or may not benefit from having several media types. But they will certainly not be hurt by having the choice. Therefore I do believe a new media type should be brought up. - Sylvain
Re: PaceEntryMediatype
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 refer to the problem I saw (doing an additional check on the root element) but Mark's comment made me realize that this is to small of a problem to warrant the media type separation of something so tied together, IMO. Are there other problems you had in mind when writing the Pace? One example. UA POSTs content to a collection. The media type chosen by the client is application/atom+xml and is accepted by the collection. Now say the client posted a feed containing several entries. What should the server decide to do? It could reject the request altogether but on what ground? How to inform properly the UA? If we had a specific media type (or at least a ;type=entry) for Atom entries you would avoid such issue or be able to return a 415 error code. More generally feed and entry documents are semantically distinct enough that they should be distinguished in their media-type one way or the other. I have hard times understanding why it hasn't been done so in the first place. Better be safe than sorry. Well it seems we are sorry :) It's interesting however because now that APP has reached a point where it stable enough to be implemented we can see that issues are not the same for server and client implementors. Considering what happens still now with HTTP (see for instance the Content-Location discussion over at the HTTP-WG) I hope the APP WG and the specification editors are taking great care to limit the possibilities of future conflicts once APP gets heavily deployed and used. If things can safely be changed now then let's do it. - Sylvain
Re: PaceEntryMediatype
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 entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Well having two media types also helps at a lower level such as HTTP (content negotiation for one thing). - Sylvain Mark. On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. - James
Re: Author element best practice
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 the condition for it (missing Content-Length or Content-Type, etc.) Since I started this thread I thought about it and I realized that an APP implementation could not foresee how it would be used and in which context. Thus it cannot safely make a decision in every use case. What amplee does is to provide callbacks to the developer who can then decide how to proceed. - Sylvain James M Snell wrote: I personally just think it's way too early for us to really be able to say much about it. So far the APP implementations that have actually been deployed seem to work rather consistently in that I can get a single client (e.g. Abdera) to work with each with very little effort and only minor variations (e.g. different auth schemes, some require Content-Length on the post, others don't, some reject invalid entries, others don't, etc). Based on my experience thus far, I really don't think it is going to be much of a problem. - James Asbjørn Ulsberg wrote: [snip] Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? [snip]
Re: PaceAutoDiscoveryDraftIsPointless
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, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. Not only that, they are actually qualified to spec changes to HTML, which is what this is. -Rob If autodiscovery is only a browser feature then indeed it has nothing to do here. But is it only meant for browsers? - Sylvain
Re: WHAT-WG, feed and alternate
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 solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). +1 very much on a new media type. The confusion carried by the current one is alarming now but will become a real issue if APP does take off. - Sylvain
Re: Author element best practice
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 accept or reject entries as they see fit. No change is necessary. Well of course if you go from a MAY to a MUST... Anyway, I agree with most comments until now that it is not a mandatory step to add to the spec. Mind you considering that RFC 4287 is very clear on what makes an Atom entry a valid one I imagine APP servers which don't have the necessary context will decide to reject the request altogether. - Sylvain
Author element best practice
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 information as to what value to set when adding the atom:author element to the member, do you think it'd be better to put an empty atom:name or to put a dummy value such as 'anonymous' or 'n/a'? I'm asking because I try to make sure that whatever the input is the member I create are respectful of section 4.1.2 of RFC 4287 and I can't decide which way to go when some information are missing from the context. Any best practices from you guys? Thanks, - Sylvain
Re: Author element best practice
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 a scenario where the author info isn't already known and not providing it is still OK. (In fact, it's hard for me to imagine a scenario in which the author info isn't already known, period.) -Tim Right. If we stretch this idea a little then, how would people feel about stating in the draft that the server MAY (SHOULD?) reject an Atom entry which would be invalid as per RFC 4287 ? I think at least a MAY would give some weigh to implementors who wish to be really strict regarding the input the allow. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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 create a media resource then it does not fall into APP to tell how this resource will be accessible. To me it's like it's not even part of the collection. - To an outsider or newcomer -- including me even though I've been following discussions closely for a while -- there's a part of the Atom model that's subtle but important to understand. Consumers of Atom feeds are supposed to look at the regular feed document, whereas publishers of Atom feeds are supposed to look at other, different resources to see how to edit or create posts. Publishers effectively look at a different feed than users do, one with extra metadata (the rel=edit links). It's a different model than that of WebDAV or IMAP, because rather than have the client specify which metadata it's interested in, the server offers two choices with different addresses. I believe it would be useful to cover that part of the model upfront in addition to the other useful stuff already there. My assumption: The separation between subscription feeds and collection feeds is not always clear. There are at least two deployed implementations I am aware of that use the same feeds for both and I'm currently working on a third. In Google's new Blogger Beta, for instance, the subscription feed is also the collection feed. I would rather have distinct feed for both always but ultimately it's still just an atom feed. Atom rules apply the same way in both cases. I fail to find a case where it can be a real issue to use the same feed. I believe that any assumption that the subscription and collections feeds will always be different is incorrect and dangerous. *Creating resources* Explicit result of POST, section 4. Are there zero, one or more resources created with a POST? There's a line at the top of section 4 which says that POST is used to create a new, dynamically-named, resource. However, that implies ONE, whereas with media entries, a POST could create TWO resources. I believe a successful POST request as described here MUST either result in one or two resources, never zero, and never 3 or more (in the absence of extensions). Section 9.5 says: A client can POST a media type other than application/atom+xml to a Collection. Such a request creates two new resources - one that corresponds to the entity sent in the request, called the Media Resource, and an associated Member Entry, called the Media Link Entry. I find that quite clear at least regarding media resource. What is the expected behavior of seeing a POST to an entry URL (rather than a collection URL)? I see that this is currently undefined; it may be worth stating that to warn clients. (I'm pretty indifferent on this one, as in this case I can't see any obvious harm in different server behaviors existing, if un-warned clients try it intentionally without knowing the results. The only possible harm is if clients got confused, did a POST to an entry URL when a collection URL was intended, and the server does a success response which creates new resources or modifies existing resources in a way the client did not expect. An error response would certainly be harmless for this undefined case but a success response could be real interesting.) I would say a server not sending a 405 or any other 40x is broken in that case. Creating entries with multiple media resources It's never explained how a client would go about creating a feed entry with a number of media resources. I imagine that it could be iterative; a client could create any of the resources at any time, and at any time after creating the feed entry, use PUT to update the feed entry to link to new media resources. I assume -- though I didn't see it stated in the document -- that it's the client's responsibility in almost all cases to put links in the feed entry to point to the media resources, otherwise the media resources are unlinked (effectively hidden to readers). My assumption: The relationship between a media link entry and a media resource is always 1-to-1. If I want an entry to point to multiple media resources, then I would create one media link entry for each media resource, then create a separate entry that points to each of the individually created media resources. e.g., entry1 -- pic1 entry2 -- pic2 entry3 -- pic3 entry4 -- pic1 -- pic2 -- pic3 Entries 1, 2 and 3 will always point to their respective media resources (using atom:content/@src). +1 The exception to this general process is if the client first uses POST to create both the media resource and the Media Link Entry in one
Python implementation of RFC4287, RFC4685 and APP
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 deserialization of feed, entry, service documents. Its underlying XMl engines are either Amara or ElementTree (although in its current state the Amara engine is the only one fully implementing the atomixlib API). amplee is a Python library implementing APP so that Python application servers can call it to create, update, delete stores, services, workspaces, members. amplee is based on atomixlib. amplee comes with a set of built-in members to generate entries from audio files such as MP3, Ogg, flac, etc. by extracting their meta-ata (ID3 tags) and filling an Atom entry with those. There is also a built-in member for ODT documents. amplee offers also a couple of built-in backends such as Subversion. More backends will be added soon. Both packages are stable but they lack documentation and aren't fully tested. I therefore don't advise you to try them right now as you may have some issues. I will released stable versions soon but yo ucan have a look in the mean time. http://trac.defuze.org/wiki/atomixlib http://trac.defuze.org/wiki/amplee Hope you will enjoy :) Thanks, - Sylvain
Re: Atom Threading Extensions, RFC 4685
FYI... The Atom Threading Extensions are now RFC 4685. - James Congrats James for this extension :D - Sylvain
Atomixlib update for you pythoners
FYI http://www.defuze.org/archives/2006/08/19/atomixlib-egg - Sylvain
Re: Language Negotiation
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 a different language you will end up with two books having each their own ISBN.
Re: Language Negotiation
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 and then the translation of that book in a different language you will end up with two books having each their own ISBN. Well, actually, once a book is published, if you later update it, you'll have to use a new ISBN, so that's probably not a good analogy⦠Indeed but wasn't I only talking about different language version of a book? I haven't talked about updating a book ;) - Sylvain
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
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 namespace or the namespace name! It's about what happens if an HTTP client dereferences that URL, which is irrelevant for the purpose of XML namespaces. My (and I assume also James') assumption is that once the specification is out, the purl.org HTTP URL will be reconfigured so that it redirects to a URL identifying the actual RFC (preferably to readable HTML :-). All of this is only necessary because the IETF insists in not minting HTTP URLs themselves. I think the argument is that they can become unstable. Of course that depends on the organization minting them and maintaining the servers, not the actual type of URI... (note that even the BCP for usage of XML in IETF specs -- RFC3470 -- mentions that it would be good if the IETF would allow URLs from www.ietf.org for this purpose). Just a thought like that but wouldn't it make sense for RFC 4287 to have specified that every standardised extension should follow the same namespace as RFC 4287? For instance RFC 4287 uses http://www.w3.org/2005/Atom Extensions should then be something like: http://www.w3.org/2005/Atom-FTE It's just a rough idea. - Sylvain
atomixlib: A Python Atom generator
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 generated documents are semantically valid and leaves that task to the higher application layers. Cheers, - Sylvain [1] http://trac.defuze.org/browser/oss/atomixlib [2] http://uche.ogbuji.net/tech/4suite/amara/ [3] http://effbot.org/zone/element-index.htm
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
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 DIV on to the consuming application with the expectation that the application is responsible for doing the right thing with it? Don't be dense. Would the parser be conformant if it passed on the feed, entry, and div elements with that expectation? I'll file a bug on UFP and I bet you it'll get fixed without a question, because there won't be a bad-faith interpretation to fight. That's two demerits this week for you. Tsk tsk. Could this teasing please stop? It noises the debate and starts being *really* annoying for all of us. If you two have issues, do that in private as this is not the right place. Thanks, - Sylvain
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
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 the in-scope xml:lang/xml:base down to child elements of the div. It also has ease-of-use ramifications on the API. So I really do need a solid answer on this one. - James Hi James, I can totally be wrong but as the div tag is added by the Atom processor when creating a content of type XHTML, I believe it should be stripped out when extracting the content to avoid altering the original meaning of the message. That's my understanding anyway. - Sylvain
Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt]
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 Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP) Author(s) : P. Saint-Andre, et al. Filename: draft-saintandre-atompub-notify-05.txt Pages : 17 Date: 2006-6-26 This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-saintandre-atompub-notify-05.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-saintandre-atompub-notify-05.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: [EMAIL PROTECTED] ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce
Re: Paging, Feed History, etc.
Definite +1 +1 as well.
Re: Paging, Feed History, etc.
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 question of what is the target of the specification and Atom in general. We mainly center the discussion around aggregators but I hope you all agree that Atom aims at much more than simple news feed, right? - Sylvain
Re: when should two entries have the same id?
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 how long before a wiki engine based on Atom :)
Re: Fyi, Apache project proposal
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. It seems to be good idea to do such promotion. However I wonder why you have not considerated using an existing project such as demokritos [1] which is quite well advanced. - Sylvain [1] http://www.jtauber.com/demokritos
Re: Fyi, Apache project proposal
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 either support other environments or at least what bridges it will offer to those, because equally to the fact Python is not suited to your needs, Java is not even on my book ;) I definitely don't want to start a language flame but I merely want to understand if that project will concern me on the long run or not. - Sylvain
Re: Fyi, Apache project proposal
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 to have a standard, free implementation that everyone uses, that is different from a reference implementation and the goals should say that. I'm sorry to ask but I'm not sure to understand the meaning of having an implementation which is exactly correct. As we have already seen on this list, RFC4287 lacks of precision in some context, therefore I wonder what being exactly correct represents. I believe Jigsaw [1] is a an example of what you mean. Sadly it seems to be hardly referenced anywhere. Besides, that does not really answer the question of whay not improving an existing project over starting a new one from scratch. Again, I don't really care about the fact it is built using Java or else as long as the project ensure bridges to other environment. - Sylvain
Re: Fyi, Apache project proposal
I believe Jigsaw [1] is a an example of what you mean. Jigsaw: http://www.w3.org/Jigsaw/ But you all knew that. ;) - Sylvain
Re: Fyi, Apache project proposal
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 cannot have an official reference implementation. The best we can do, in this case, is to have a number of implementations available that strive to a) implement the spec as completely as possible and b) interoperate with one another as best as possible. The reference implementation then becomes a union of everything these available alternatives seem to get right. We made a mistake calling our stuff a reference implementation but it was an honest one born out of frustration trying to come up with a name our lawyers would actually clear (naming the damn thing was actually holding up our ability to open source it).
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
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
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
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
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
[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 update mechanism
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
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
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
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
Feed update mechanism
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 as it wastes so much bandwith specially when the said feed contains all entries being produced on the server. Below are ideas I had about that issue. Nothing formal. PROPOSAL 1 == 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again and provide the If-Modified-Since header a. No changes done, the server returns a 304 Not Modified b. The server checks which entries have been updated or published since that date and returns a feed containing only those. The UA updates its copy of the feed with the incoming data. The big issue with this algorithm is that it adds semantic to the HTTP caching system by expecting the UA to update its copy of the feed instead of simply replacing it. Although specific aggregators could do it, it is more than likely that some clients would just replace their copy of the feed and confuse the end user. PROPOSAL 2 == 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again but provides a time range like this: http://host/feed?after=2003-12-13T18:30:02Zbefore=2003-12-13T19:30:02Z a. No changes done, the server returns a 304 Not Modified b. If entries have been published or updated in the time range, then return a feed with those only. Of course, one might only pass either 'after' or 'before'. The problem with this proposal is to add parameters to the URI which might not be handled by the server. There are a few ways to handle that: * The UA could also use the OPTIONS method from HTTP to check if the server supports the said URI. * The client sends the requests and the server could return 400 Bad Request if it cannot handle it. In order to deal with those proposals we could add a simple extension to a feed such as atom:feed update-method=full|incremental|chunk When receiving the feed for the first time the client would know if it can either request for: * full = default to fetch the complete feed each time when it has been modified. The default behavior as it exists today. * incremental = the server says it can serve entries published or updated after a given date (equivalent to using only the 'after' parameter in PROPOSAL 2 or PROPOSAL 1) * chunk = the server says it can serve feed of entries published or updated between two dates (as explained in PROPOSAL 2) These are just some thoughts and there might already be ways of dealing with this. If not I'd be happy to hearing your feedback. - Sylvain http://www.defuze.org
Re: Feed update mechanism
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 idea is pretty neat and efficient apparently. I'll give it a look. Thanks, - Sylvain
Re: Entry types
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) duck-typing, eg assuming that contact:firstName implies the type. In order of preferences: c, a, b, d I think that using category might be an overloading of the semantics of category?, Well RFC 4287 says for atom:category This specification assigns no meaning to the content (if any) of this element Therefore I guess it would be fine from the spec point of view. However I do agree with you that it would be overloading the general meaning we give to a category. I'm not sure, it probably depends on the circumstances. Category is really a summary of the set of real-world concepts the entry is about, it ought to be under control of the publisher. Agreed. I suppose a quick vcard:* check is pretty easy with XPath. Second that point too. - Sylvain
Re: Changing feed thread
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 concerns about extending atom:link... +1 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? +1 although I'm less annoyed by this one if you keep it as it is now. My apologies if I came across a little too heavy handed on this. That was most definitely *not* the intention. Thank you very much for the feedback then as I was getting afraid we would not be able to simply discuss around here :D So thank you. - Sylvain
Re: Atom Thread Feed syntax
Just wanted to follow through on this for everyone. Given that there are vendors getting ready to ship code based on the current rev of the spec, I'm *not* going to rename the id attribute to ref. Yes, I know that id is confusing to some folks, but we're just talking the name of a single attribute and not a critical functional bug. From this point forward, only critical spec bugs will be fixed and I will be submitting the spec for consideration as a standards track RFC in the not too distant future. - James First of all thanks for the follow-up, this is appreciated. Now I do understand your motivation at keeping the name of the attribute and I also believe people that will be reading such feed won't make the mistake. Fir enough. It's not that a big deal... or is it? I do find a bit hard to swallow though the implemantators do it that way so let's not update the RFC which is still a draft, even if an advanced one. I simply wonder what is worse, to annoy a few vendors now or a wider audience in the future. Anyway, so be it. I won't argue and I leave you the final word on this one ;) - Sylvain
Re: atom:name ... text or html?
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
Re: Atom Thread Feed syntax
Considering the above-mentioned symmetry with @href, I’m coming around to whose-ever view it was that this attribute should be called @ref for balance. +1 for @ref as well.
Atom Thread Feed syntax
Hi everyone, I was reading the Atom Feed Thread draft [1] yesterday and I ran into a problem as I described in my blog [2]. To recap the 'in-reply-to' element defined in that specification takes an 'id' attribute that specifies /the universally unique identifier of the resource being responded to/. Calling such an attribute 'id' is a mistake in my opinion as it confuses with the actual ID of the element itself within the XML document it belongs to and it makes impossible for another element within the document to have the same value as an 'id'. I would rather move the content of that attribute as a text element of the 'in-reply-to' element (as does the atom:id element). Thoughts? - Sylvain [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-05.txt [2] http://www.defuze.org/archives/2006/03/14/about-atom-feed-threads
Re: Atom Thread Feed syntax
Hello Thomas, It could lead to confusion, but as Atom doesn't define such an attribute in its own namespace (or on elements in its own namespace) and as no other extension that I know of do that either, I don't think it really matters… You are right Atom does not define such an attribute but I'd be happier if extensions could follow Atom conventions as well. Atom sets the atom:id value not as in an attribute of atom:id but as its content. Why not following the convention in the first place? Besides the fact there is no other extension to do so as of yet is quite irrelevant to me. Atom extensions are fairly young and hopefully they'll be more and more spreaded. I'm sorry to have to tell you that you *are* mistaken… Having an attribute named id doesn't make it an ID (in the sense of a unique identifier throughout the document, such as the ID type in a DTD of xs:ID in XMLSchema), otherwise: - you wouldn't have to declare them explicitely in your DTDs and there wouldn't be a need for an ID (resp. xs:ID) type in DTD (resp. XMLSchema) - the validity constraint One ID Per Element Type [http://www.w3.org/TR/REC-xml/#one-id-per-el] could never be met as soon as you'd declare an ID attribute with a name different from id - there wouldn't have been a need for xml:id [http://www.w3.org/TR/xml-id/] Again this is a matter of convention in my opinion. When reading an XML document I don't want to be obliged to think about the actual meaning of an id attribute. You are indeed right (and thank you for explaining it to me) in terms of specification but conventions are often as important. Specially for people like me who are not XML guru. Thanks for your feedback by the way :) - Sylvain
