Hi, We're planning on a jaxp project to address usability issues in the JAXP API. One of the complaints about the JAXP API is the number of lines of code that are needed to implement a simple task. Tasks that should take one or two lines often take ten or twelve lines instead. Consider the following example: File file = new File(FILEPATH + "results.xml"); DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); XPathFactory xf = XPathFactory.newInstance(); XPath xp = xf.newXPath(); xp.setNamespaceContext(new NamespaceContext() { @Override public String getNamespaceURI(String prefix) { return "http://example.com/users/"; } @Override public String getPrefix(String namespaceURI) { return "ns1"; } @Override public Iterator getPrefixes(String namespaceURI) { ArrayList list = new ArrayList(); list.add("ns1"); return list.iterator(); } }); try { DocumentBuilder builder = factory.newDocumentBuilder(); Document document = builder.parse(file); String s = (String) xp.evaluate( "/ns1:Results/ns1:Row[ns1:USERID=2]/ns1:NAME[text()]", document, XPathConstants.STRING); System.out.println("Company: " + s); } catch (ParserConfigurationException e) { //creating DocumentBuilder } catch (SAXException ex) { //parsing } catch (IOException ex) { //parsing } catch (XPathExpressionException ex) { //xpath evaluation } The issues reflected in the above sample include: *1. Too many abstractions* As shown in the above sample, there are multiple layers of abstraction in the DOM and Xpath API: factory, builder, and document, XPathFactory and XPath. *2. Unnecessary Pluggability* The pluggability layer allows easily plugging in third party implementations. However, in many use cases where pluggability is not needed, it becomes the performance bottleneck for the applications. *3. Too many unrelated checked exceptions* There are four unrelated checked exceptions in the above example. None of them is recoverable. ParserConfigurationException actually reflects a design flaw in the DocumentBuilderFactory that allowed setting both a Schema and Schema Language. In practice, Exception is often used to avoid having to catch each of the checked exceptions. *4. Lack of integration* JAXP is an umbrella of several libraries. The sample code above demonstrated the lack of integration among them. First of all, A DOM Document and XPath have to be created separately. Secondly, as in the above case, the Document may be either namespace-aware or unaware, depending on the setting on the DOM Factory, which is unknown to XPath created later. This project may have two aspects: one to provide APIs to get straight to the objects such as DOM Document, and another to provide convenient methods for some common use cases. (*Note that, there is no intention to replace the existing API nor duplicate all of the features.) For the example above, it could potentially be done in a couple of lines (this is just an illustration on how existing APIs could be simplified and may not reflect what the API would look like): String company = XMLDocument.fromFile(FILEPATH + "results.xml") .evalXPath("/Results/Row[USERID=2]/NAME[text()]"); System.out.printf("Company: %s%n", company); We would love to hear from you. Any thoughts, concerns, experiences/complaints would be very welcome. Thanks, Joe