[Standards] XEP-0258 and XEP-0060

Ralph Meijer ralphm at ik.nu
Fri Nov 18 11:12:58 UTC 2011

On Fri, 2011-11-18 at 10:53 +0000, Ashley Ward wrote:
> On 18/11/2011 06:47, "Ralph Meijer" <ralphm at ik.nu> wrote:
> >On Thu, Nov 17, 2011 at 07:55:09PM +0000, Ashley Ward wrote:
> >> On 17/11/2011 18:53, "Ralph Meijer" <ralphm at ik.nu> wrote:
> >> [..]
> >>Yeah. I think it would make most sense for the label to be contained
> >> within the <item> element, and I believe XEP-0060 already allows the
> >> <item> element to contain a sequence of any xml elements, so
> >>implementing
> >> this in XEP-0258 shouldn't require any change to XEP-0060.
> >
> >Alas, this is incorrect. An <item/> element MUST NOT have more than one
> >child element. See the schema. If present, the child element is the
> >payload. This restriction doesn't apply to other elements, so I think it
> >/would/ be ok to have the <securitylabel/> elements as a sibling of
> ><item/>.
> You're right. Looking closer at the xml spec for XEP-0060 you can only
> have one child of an <item/>.
> I don't think it could be a sibling of <item> as the <publish> element can
> only contain a list of <item/> elements.

Actually no. In general you can put unknown elements anywhere. Code
shouldn't break because of additional elements. However, the schemas for
the <item/> element (both pubsub and pubsub#event) specifically captures
all namespaces using <xs:any namespace="##other"/>. With the maxOccurs
defaulting to 1, this effectively disallows more than one child element
of <item/>. But not anywhere else.

I don't see any reason why you couldn't add <securitylabel/> as a child
of <publish/> next to <item/>.

> (I suppose we could introduce another element type which can contain the
> <event/> and the <securitylabel/> element and make this the child of the
> <item/> - but this feels wrong!)

Again, notification messages are not an issue, because you can have
unlimited sibling elements of <event/>. I would strongly prefer these to
keep similar form to other <message/> stanzas, and not bury them deep

This reminds me of a conversation I had with Blaine Cook about pubsub
events, where he actually preferred the item's payload to be outside of
the <item/> in notifications, because non-pubsub-aware clients could
still parse the Atom entry. But I digress.


More information about the Standards mailing list