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

Peter Saint-Andre stpeter at stpeter.im
Fri Jun 4 22:52:08 UTC 2010

On 2/25/10 8:07 PM, Florian Zeitz wrote:
> Hi,

Hallo, and sorry about the seriously delayed reply.

> I noticed there is a difference between XEP-0048 Example 3 and XEP-0223
> Example 1, which describe exactly the same process if I understand
> correctly.

Good catch.

> Examples in XEP-0223 don't wrap the bookmark in a <storage/> element.
> It has recently been noted by someone in the Gajim's MUC that it would
> be good to store one bookmark per item.

That's the question, isn't it?

> If you do this, it means that a <storage/> element would be unnecessary
> overhead. OTOH if you also need to support Private XML Storage it means
> you'd store quite different things in PubSub and in Private XML Storage.

True. I thought about this quite a bit while working on XEP-0223 and I
admit that I fudged it in the spec because we were in a hurry to push it
out. But I think we need to be clearer about this issue.

> So, while the XEPs should be harmonized I wonder which way we should go.

So do I. I'll number your alternatives:

1. drop <storage/> and suggest storing one bookmark per <item/>

2. keep <storage/> and store one bookmark per <item/>

I don't see a big difference between 1 and 2, unless you think that
removing the <storage/> wrapper will explicitly limit us to one bookmark
per item.

However, note that in XEP-0048 the <storage/> element can also contain a
<url/> child to store bookmarks to web pages! So removing the wrapper
would change the meaning to either conferences or URLs, but not both.

Those considerations would lead me to prefer 1 over 2.

3. keep <storage/> and store all bookmarks in one <item/>

This makes more sense to me nowadays. Here's why:

a. It maps directly to XEP-0048, except now you've got pushes for
updates etc.

b. Most people have few bookmarks (URL storage isn't supported in any
clients that I know of, and even power users have perhaps a dozen rooms

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

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

d. Putting everything in one item is more consistent with the last
published item functionality in PEP.

4. something completely different.

I can't think of something completely different, because I think that 1
and 3 are the primary alternatives.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100604/35eba3eb/attachment.bin>

More information about the Standards mailing list