OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [proposal] XPath API for Java

[ Lists Home | Date Index | Thread Index ]

Hi, Bill --

> 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.

It is possible, as you observe, to put the Xalan, Saxon, or Jaxen stuff 
behind a clean interface and the Java type system.  (There is also 

> So here's a proposed api:
> [SNIP]
>     List match( Node target, String xpath, Map namespaces );

You'll also need to allow for variables to be set and for extension 
functions to be configured.  I haven't looked at the Jaxen API in a 
while, but I recall it being minimal and general.  Perhaps a first pass 
would be to take the Jaxen APIs and then pull out a set of general 

It is also useful to allow the first argument to be a Collection 
instead of a Node only.

What about support for keys and ids?

> 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.

[G]ood [o]ld [r]aisins and [p]eanuts?

I'm on the other side of the fence, as are other people who use XPath 
expressions for routing logic and similar repeated execution.  Things 
like keys and ids suggest that you want initialization and caching on a 
per-document level.

Just some thoughts.

	-- Paul


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS