Re: [Standards] Collection Oversights in XEP-0060
At http://mail.jabber.org/pipermail/standards/2008-June/019234.html (sorry, I lost the original message) Nathan Fritz wrote: Examples 216 and 219, the notification of disassociation/association are neither a followup of the example that they show, nor does the collection have a node reference. The attribute id is mentioned as being in the associate/disassociate element, when in fact node is used. Fixed: http://is.gd/KJH In short, the example doesn't match the text (nor does it flow with the previous examples), and the receiving entity has no idea which collection node is being updated just based on this notification. Section 9.2 has a similar inconsistency between the id attribute being mentioned in the text and the node attribute being used in the example, however the lack node attribute in the collection attribute is understandable for the root collection. Ralph and I agreed that if we're talking about the root collection node, the value of the NodeID needs to be empty, that is: collection node= Section 9.7 is not clear whether this item subscription is recursive. Will it update me of collections within collections within collections? If an item is published to a (leaf) node, anyone who is subscribed to a collection that aggregates that leaf node will receive the item, even if there are other intermediate collections between the leaf node and the subscribed collection. Or at least that's how things work today. This enables you to have multiple aggregation points within the pubsub system. See also this: http://www.xmpp.org/extensions/tmp/xep-0060-1.12.html#collections-models I may add pictures for all those different models so that people can understand it more easily. :) Peter smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Collection Oversights in XEP-0060
Examples 216 and 219, the notification of disassociation/association are neither a followup of the example that they show, nor does the collection have a node reference. The attribute id is mentioned as being in the associate/disassociate element, when in fact node is used. In short, the example doesn't match the text (nor does it flow with the previous examples), and the receiving entity has no idea which collection node is being updated just based on this notification. Section 9.2 has a similar inconsistency between the id attribute being mentioned in the text and the node attribute being used in the example, however the lack node attribute in the collection attribute is understandable for the root collection. Section 9.7 is not clear whether this item subscription is recursive. Will it update me of collections within collections within collections? Thanks, Nathan Fritz
Re: [Standards] Collection Oversights in XEP-0060
On Thu, Jun 26, 2008 at 01:53:21PM -0700, Nathan Fritz wrote: Examples 216 and 219, the notification of disassociation/association are neither a followup of the example that they show, nor does the collection have a node reference. The attribute id is mentioned as being in the associate/disassociate element, when in fact node is used. In short, the example doesn't match the text (nor does it flow with the previous examples), and the receiving entity has no idea which collection node is being updated just based on this notification. Section 9.2 has a similar inconsistency between the id attribute being mentioned in the text and the node attribute being used in the example, however the lack node attribute in the collection attribute is understandable for the root collection. Section 9.7 is not clear whether this item subscription is recursive. Will it update me of collections within collections within collections? Have you looked at the in-progress version? It contains some clarifications to the text about collection nodes. Details here: http://www.xmpp.org/extensions/tmp/xep-0060-1.12.html http://mail.jabber.org/pipermail/standards/2008-June/019107.html http://is.gd/w1g Please check out those links and let me know if your questions have or have not been answered. Peter
