[jdev] Monthly XMPP Meeting

Brett Zamir brettz9 at yahoo.com
Thu Mar 12 21:18:17 CDT 2009

> From: Norman Rasmussen <norman at rasmussen.co.za>
> To: Jabber/XMPP software development list <jdev at jabber.org>
> Sent: Friday, March 13, 2009 6:25:03 AM
> Subject: Re: [jdev] Monthly XMPP Meeting
> On Thu, Mar 12, 2009 at 8:07 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> 2) RFC3921bis-08: "The <show/> element MUST NOT possess any attributes."
>> (also with <status/>, <priority/>, <body/>, <subject/>)
>> The latter could be made to state "MUST NOT possess any non-namespaced
>> attributes".
> IMHO we don't need to change the schemas for those elements. But it
> would be clearer to say "there are no attributes defined for these
> elements".
> I agree - those elements don't allow sub-elements (from the same or other namespaces), so why should they allow attributes?
> Note that point #2 only applies to the show, status, priority, body, subject elements (not message/presence/iq). 
>  Nothing is stopping you from creating 'sibling' elements to these in the same stanza with whatever element and 
> attributes you want.

It sounds like Peter was essentially agreeing that attributes need not be restricted by the spec. I also agree with his point about not needing to change the schema, as it is reasonable not to explicitly allow other namespaced attributes in the schemas, since schema languages tend, very unfortunately in my opinion, not to allow other namespaced attributes by default, and it would be cumbersome to reflect such allowances everywhere, and might seem to imply we were encouraging rather than simply allowing their use. 

But it would be great, if the RFC could be reworded not to be so exlusive. There's really no good reason not to allow them. Yes, you can add child elements, but that might not be as semantically appealing (e.g., attributes fill a unique role in indicating meta-data for a tag--it'd be more clear what the namespaced data was referring to), nor as structurally convenient. Let 1000 namespaces bloom... :)


More information about the JDev mailing list