[Standards] Namespace versioning

Dave Cridland dave at cridland.net
Thu May 19 11:43:56 UTC 2011

On Thu May 19 08:24:43 2011, Jacek Konieczny wrote:
> Yes. It is wrong before <dialback  
> xmlns='urn:xmpp:features:dialback:1'/>
> is a totally different element than <dialback  
> xmlns='urn:xmpp:features:dialback' />.
> It is not a new version, it is a new protocol. And a new namespace.  
> Why
> would we want that?
> That is the always returning problem with XMPP protocols –  
> treating the
> namespace like an attribute. It is not an attribute, it is a part of
> element name.  '<a xmlns="a"/>' is different from '<a xmlns="b"/>'  
> the
> same way '<a/>' is different from '<b/>'. Namespaces give us
> availability to use e.g. '<error/>' element in different protocols  
> in a
> different way, for a different purpose. They should not be used to  
> give
> extra meaning to an existing element.

Since I think this'd be the third time this month I'd try to explain  
namespace versioning, please just read the attached. FWIW, the vast  
majority of people working on XMPP (including I might add everyone  
contributing to this thread, as far as I know) do understand XML  
namespaces. The way we allocate namespaces is, however, fairly  
confusing when you see it and I don't blame you for (apparently)  
misunderstanding it.

Also, Peter, Oh Mighty XEP Editor, I apologise for its rough form,  
but hereby submit it as an Informational XEP to provide background  
reading for, and expansion on, XEP-0053§4. I beseech thee, as well  
as those nice chaps on the Council, to help me clear it up a bit, too.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xep-nsv.xml
Type: application/xml
Size: 6108 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110519/8d71b96a/attachment.xml>

More information about the Standards mailing list