[Standards] Namespace versioning
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards