[Standards] Namespace versioning

Mark Rejhon markybox at gmail.com
Wed May 25 19:54:43 UTC 2011

A good default response, but given more info about situation, it's not an
XML library bug: Most XML libraries would permit me to do this: It's just an
ordinary XML parsing library -- using Google's open source XMPP librar!
 Just that I could manually monitor the xmlns attribute and use, say, a
*separate* regex object (not a native part of XML library or XMPP library)
to pattern-match a namespace to my heart's content.  It's just I then used
the Java Smack library which forces me either to manually parse the XML
using a serial-based xmlpull, or trap events on a very specific xmlns, which
teaches me that I *don't* always have the option of peeking the xmlns
attribute directly.

Yes, perhaps incorrect monitoring of namespace (blame me), but it's not an
XML library bug (blame the library).

It does clearly illustrate the need for a versioning best-practices XMPP
informational XEP like suggested. :-)

Mark Rejhon

On Wed, May 25, 2011 at 3:47 PM, Joe Hildebrand <joe.hildebrand at webex.com>wrote:

> On 5/25/11 10:00 AM, "Mark Rejhon" <markybox at gmail.com> wrote:
> > 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.
> The first library has a bug.
> --
> Joe Hildebrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110525/49a47691/attachment.html>

More information about the Standards mailing list