[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX Filters for Namespace Processing
- From: Tom Bradford <firstname.lastname@example.org>
- To: Jonathan Borden <email@example.com>
- Date: Sun, 05 Aug 2001 13:32:13 -0700
Jonathan Borden wrote:
> As a -user- of XPath, I didn't expect that I'd have to request namespace
> support in an implementation, just as we might argue that English is not
> designed in a logical fashion, I happen to know it and aren't sure that I'd
> ever getting around to learning or using the 'fixed' version.
I truly appreciate your snide criticism.
The reason it wasn't there is because in order to support namespaces,
most XPath implementations require a context node for prefix
resolution. The context node is usually an element in the document that
is being queried, and it's usually an element that has been sufficiently
drilled down to so that the prefix you use in the XPath actually matches
the namespace you're looking for.
When you query across a set of documents where the same namespaces may
be present, but the documents use different prefixes, or no prefixes at
all, you need a way of making those namespaces make sense in the context
of the query over the collection as a whole. A prefix as defined from
one document to the next, or even within a single document, may resolve
to a completely different URI, and so just performing a query with a
bunch of prefixes in it won't yield the proper results.
So we (still) need to define a way to synthesize a context node for use
with the XML:DB API. Not with dbXML mind you, the namespace support is
there, but we still can't expose it.
But you're on the XML:DB lists, so you already know this.