[Standards] Divergence between XEP-0048 and XEP-0223

Kevin Smith kevin at kismith.co.uk
Sat Jun 5 15:27:34 UTC 2010

On Sat, Jun 5, 2010 at 2:28 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> c. It seems a bit strange to me for each bookmark to be a separate item,
>>> because conceptually "my bookmarks" seems to be its own entity (I don't
>>> think of each bookmark as a separate thing that needs to be handled
>>> differently).
>>> However, Section 4 of XEP-0223 disagrees:
>>>    Each item published to the node is a logically separate instance of
>>>    the data to be stored. It is the responsibility of the publishing
>>>    and receiving entities to construct a complete view of all such
>>>    items, if desired. For example, each bookmark published to a private
>>>    data node is a separate piece of data, whereas the history of all
>>>    items published to the node provides a complete list of the user's
>>>    bookmarks.

>> Actually this is what spawned my XEP reading. mcepl asked in gajim@ why
>> it wasn't one bookmark per item. He was writing some bookmark management
>> script IIRC.
>> Modifying bookmarks becomes a lot easier if you don't have to download
>> all of them, modify the XML and upload everything again (even though you
>> didn't touch most of it).
>> If you have one bookmark per item you can just modify that specific item.

Having all the bookmarks in one item makes it difficult to handle
extensibility sensibly - a client gets the list of bookmarks, builds
its model of the bookmarks, and that's fine. Then the user adds a new
bookmark, and any extensions that a previous client has stored get
removed - it's possible to avoid this, but it makes the client's life
unnecessarily difficult. If bookmarks are one per item, you can add
new bookmarks as much as you like without worrying about damaging old

> So: I think we need to reconsider these non-extended-presence scenarios
> and figure out better ways to handle them. That might necessitate new
> profiles of PubSub (other than PEP). Yes, it sound kind of messy, but it
> can't be uglier than what we have in XEPs 222 and 223. ;-)

I don't think new profiles of PubSub are particularly nasty - forcing
anything more into XEP-0060 is something to be avoided at all costs,
but profiles and extensions seem fine.


More information about the Standards mailing list