[Standards] Pubsub to atom mapping :)

Sergey Dobrov binary at jrudevels.org
Mon Feb 27 07:36:18 UTC 2012


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.




More information about the Standards mailing list