[Standards] Pubsub to atom mapping :)
binary at jrudevels.org
Fri Feb 24 13:10:19 UTC 2012
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
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,
XMPP Developer and JRuDevels.org founder.
More information about the Standards