I realize that stripping the namespaces isn't the most elegant of solutions,
but in regards to XPath I am not using XSLT stylesheets. I'm trying to use
XPath programmically, and according to the xalan faq there really isn't
anyway to get around the default namespace problem. Maybe I just don't know
that best practices for parsing xml documents, but it seems like there is no
way to get to a singular text node deep in a tree without doing a bunch of
Document.getElementsByTagName().getItems().getFirstChild() and so on.
Conceptually it's much easier to just do an String whatever =
org.apache.xpath.XPathAPI.selectSingleNode("/path/to/some/node/text()"). For
example, if i wanted to build purely a data object without using something
like XPath, it seems to leave me with only two options. I could either
iterate the entire DOM tree, testing nodes and storing their values in
member variables within the class, and then working with the member
variables. Or, i could just iterator through the tree specifically looking
for something when i need it. The first way is not memory friendly, the
latter is not performance friendly. Am i completely wrong here?
-----Original Message-----
From: Joseph Kesselman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 30, 2002 8:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Stripping namespaces from a document
Stripping namespaces would mean stripping semantic information from the
document; I don't think there's been any demand for this.
Have you considered rewriting your stylesheet? XPath and XSLT don't handle
default namespaces as defaults, but they *CAN* handle documents which
*use* default namespaces just fine, by specifying prefixes in the
stylesheet. Remember, namespace-based processing is sensitive only to the
namespace URI, not which prefix (or default) was used to select that URI.
If you really insist on ignoring namespaces -- BAD idea in almost all
cases -- XPath and XSLT can still be used, but you'd have to explicitly
match/select the nodes using predicates that test name() and/or
local-name().
______________________________________
Joe Kesselman / IBM Research
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
