Lists Home |
Date Index |
JSR 206, which is defining JAXP 1.3 is undergoing community review at
the moment, the activity includes work on an XPath API.
> -----Original Message-----
> From: Bill de hÓra [mailto:firstname.lastname@example.org]
> Sent: 20 September 2003 19:08
> To: email@example.com
> Subject: [xml-dev] [proposal] XPath API for Java
> I've been through a ton of DOM-in-Java programming in the last 12
> months. You learn early on to use XPaths where possible to keep the
> code flexible and clean. But one of the annoying about using XPath
> in Java is that it's all library specific. The last thing I want to
> have to do is go through all my code and replace Xalan stuff with
> Jaxen stuff or Jaxen stuff with DOML3 stuff.
> So here's a proposed api:
> package net.amadan.markup.xpath;
> import java.util.Map;
> import org.w3c.dom.Node;
> public interface XPath
> * Match a xpath over a DOM Node.<p>
> * @param target the Node to match against.
> * @param xpath the xpath as a String
> * @param namespaces keys are namespace URIs,
> * values are namespace prefixes.
> * @return the Nodes matching the expression, a size of 0
> indicates no match.
> * @throws IllegalArgumentException if the xpath is illegal or a
> prefix is not bound to a key in <tt>namespaces</tt>
> List match( Node target, String xpath, Map namespaces );
> I don't ever seem to need the extra step of preparing an xpath
> object and applying it later to a Node. I also figure managing any
> expression caching and so on is a fun thing to do for the
> implementor but gorp for the user.
> Next step is a factory/plugin to this so anyone that does xpath in
> java can register a provider. It'll be the usual
> "FactoryFactory.getFactory().newInstance()" dance using a System
> property ("net.amadan.markup.xpath.driver").
> Bill de hÓra
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription