On Wed, May 25, 2011 at 6:57 PM, Joe Hildebrand <[email protected]>wrote:
> On 5/25/11 2:17 PM, "Glenn Maynard" <[email protected]> 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
