[Standards] Namespace versioning

Glenn Maynard glenn at zewt.org
Wed May 25 23:48:15 UTC 2011


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

> On 5/25/11 2:17 PM, "Glenn Maynard" <glenn at zewt.org> wrote:
>
> >> The first library has a bug.
> >
> > An XML library supporting namespace filtering based on wildcards has a
> > "bug"?  You can even do that with XPath.
>
> I would argue that almost(1) every time you do, it's a bug in your software
> using XPath. :)
>

Usually, but it's not a bug in the XML library itself.  :)

Mark's use case seems to be watching for unknown protocol versions to notify
the end-user to upgrade.  That's not too far out there--you're not actually
looking at the data within the namespace, which you know nothing
about--though it doesn't actually seem like a good idea.  You don't want to
nag users to update based on this; it may be an experimental protocol
version, a new spec version which you havn't implemented yet, etc.

Seriously, namespace URIs are just opaque strings.  They have no structure.
> Two URIs that aren't an exact codepoint-for-codepoint match are completely
> and totally unrelated.  Performing regex or starts-with matches on them
> almost(1) always means you've got a problem with how you think about XML.
>

Namespaces are opaque *to XML*, as filenames are opaque to a Unix system; as
with filenames, structure can be assigned to namespaces in higher-level
contexts.  For example, it could be done to permit hierarchical namespace
filtering.  In all cases, though, you should never be looking at the
*contents* of a node until you have an exact match for a known namespace.

In any case, XMPP has no such structure.

-- 
Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110525/bd87968b/attachment.html>


More information about the Standards mailing list