To date, I had the opportunity to implement my prototype standard (upcoming resubmission) in two different programming languages -- C# and Java. I learned that different XML libraries handles namespace versioning very differently. With one XML library, I was able to monitor all namespaces that matched a specific wildcard, which is useful for translating that to the end user warning that a software upgrade is needed. But for a different XML library, my software was 100% blissfully ignorant of all namespaces that did not have an exact match. So it was not possible (or easy) to translate that to a warning to the user to upgrade the software.
This is more especially important during the "beta" stage (i.e. year 2011, or part of 2012), while the specification is during a draft stage. Nontheless, if necessary I can still use other techniques of software version negotiation, if necessary (there's already XMPP specification for that, from what I recall). (I am also in collaboration with a emergency 911 center that is considering implementing my spec, so I am under some pressure, too.) On Thu, May 19, 2011 at 7:43 AM, Dave Cridland <d...@cridland.net> wrote: > 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. > -- > Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
