The composition model is not yet well specified in XEP-0222 and XEP-0223. By "composition" I mean how a receiving entity should construct a full set of items, if desired. For example, if you publish your bookmarks to a node whose NodeID is "storage:bookmarks" then I assume that each published item would look something like this (this is different from what's in XEP-0223 right now because I have removed the <storage/> wrapper per Council discussion):
<iq from='[EMAIL PROTECTED]/balcony' type='set' id='pdp1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <publish node='storage:bookmarks'> <item> <conference xmlns='storage:bookmarks' autojoin='true' jid='[EMAIL PROTECTED]' name='The Play's the Thing'> <nick>JC</nick> <password>Gl0b3</password> </conference> </item> </publish> </pubsub> </iq> This means that 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 comprises a complete list of the user's bookmarks. This history may include items that are republished with an existing ItemID (thus overwriting the previous version of that item). I think this may imply that each protocol that uses this approach needs to specify what an "instance of the data" is. To choose another example, consider User Profile data (XEP-0154). Here, each instance is a field from an x:data form: <iq type='set' id='pub1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <publish node='urn:xmpp:tmp:profile'> <field xmlns='jabber:x:data' var='weblog'> <value>http://www.denmark.lit/blogs/princely_musings</value> </field> </publish> </pubsub> </iq> So here the payload namespace is 'jabber:x:data' whereas the NodeID is 'urn:xmpp:tmp:profile'! To my mind this phenomenon (if we decide to go down this path) provides further ammunition for differentiating between notification-by-NodeID and notification-by-payload namespace using +notify caps features for the former and +filter caps features for the latter: http://mail.jabber.org/pipermail/standards/2008-May/018810.html I'm not quite sure about this whole composition problem, but the foregoing seems sensible to me. Feedback is welcome as always. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
