I think now that the second option is more suiting: it will be easier to add the ability to view item's revisions than make some kind of item grouping.
The other thing here is linking: atom:link needs attributes "ref" and "href", but href usually points to the atom feed at all and ref points to the specific entry in the feed by it's atom:id. Then, should we point to the node there and not to the specific item in the node? Then we can exclude atom:id from entries as superfluous. Have we to change Atom's xmlns then? Any opinions? On 02/24/2012 08:10 PM, Sergey Dobrov wrote: > Hello, > > Pubsub specifications often refers to the Atom format as a payload. > Nevertheless, there are some confusing things that makes it hard to > understand how to map atom to pubsub in some cases that are outside of > the specifications. The reason I want to solve them is in XEP-277 which > I need to update to implement some of must have feature into my > microblogging platform. > > Here I suggest to discuss these problems. > > The hardest problem here is how to map atom:id > (http://tools.ietf.org/html/rfc4287#page-19) element to the pubsub item > id and closely connected to it problem with the "Update" post feature. > > The problem is that we have two different entry id fields and it very > important to understand which means what to make protocol useful. > > I see two possible ways here: > > 1) pubsub item id identifies the concrete revision of an item. Thus, if > we have to update the item then we just post a new item to the node with > the same atom:id and another pubsub id. Benefit here is that if we link > from another place to this item (for example, in the <in-reply-to>) then > it will be a link to this concrete revision and will never confuse with > other revisions. Another benefit is that we can to track any changes to > the entry since all of them are stored in the node. But this option has > one strong disadvantage: we have no way to group these entries to make > it possible, for example, to retract the entry entirely with all of it's > revisions. I have no idea how we can solve the issue yet. > > 2) pubsub item id = atom:id. Thus, if we have to update the item then we > just update the item. :) Possibly, we need to refuse to use atom:id in > payload at all since it's confusing to have two identities that means > the same thing. How to address the entry then? > > Thanks for your attentions, I hope that I was clear enough. > > Have a good weekend, btw. :) > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
