The Java API for XML Processing, or JAXP for short, enables applications to parse and transform XML documents using an API that is independent of a particular XML processor implementation. JAXP also provides a pluggability feature which enables applications to easily switch between particular XML processor implementations. To achieve the goal of XML processor independence, an application should limit itself to the JAXP API and avoid implementation-dependent APIs and behavior.

A PDF version of the JAXP 1.1 specification can be found by following this link. In addition, there is a JAXP 1.2 maintanence specification that adds support of W3C XML Schema and is based on the previous JAXP 1.1 specification.

One place to ask questions about JAXP is with the provider of your implementation. For example, if you are using the Apache Xerces parser, use the xerces-j-user mailing list. For Apache implementations, see the XML mailing lists page for subscription information. One location where you can find Apache mailing list archives is at MARC. JAXP has a namespaceAware property that is directly tied to the SAX 2.0 "http://xml.

J2EE Reference Implementation version 1.3 or later -- contains a recent JAXP RI version, but may not be the latest. To approximate an unbundled version, you can also download the major components individually from Apache. See the question on source code for more information.

Since at the time of this writing Sun does not provide one, I will try to maintain a browsable online version of the JAXP RI docs. The JAXP RI docs also contain a link to the JAXP API javadoc.

The JAXP RI is based on open sourced code. Although Sun no longer provides a free source distribution (there might be a way to pay for one), you can obtain the same source code from the Apache CVS repositories. For example, the JAXP RI 1.2.0 release consists of: Note: there may be some differences with the actual JAXP RI. For example, the JAXP RI comes with documentation which is not yet available at Apache.

will do the trick, provided you set your CLASSPATH correctly. If you are using j2sdk1.4.1_01, it will be always right as long as you can use java. In j2sdk1.4.1_01, xml stuff is bundled inside rt.jar already. My xerces/crimson parser does not validate for me? The following code does not work, why? org.apache.xerces.parsers.SAXParser parser = new org.apache.xerces.parsers.SAXParser(); // MyDefaultHandler extends DefaultHandler parser.setContentHandleler(new MyDefaultHandler()); parser.

If your application needs to programmatically perform XSLT transformations, then you need an implementation that supports the transform parts of the JAXP API. One resource that provides sample code for this type of application is the Xalan-J documentation. If not, then your application is a pure parsing application and you need to decide between using the DOM or SAX APIs.

JAXP enables your application to be implementation-independent, but it does not enforce this constraint. For example, if your instance XML documents use character encodings that are not required to be supported by the XML REC, then this may cause compatibility problems. You may have tested your application with a JAXP parser that implements an optional character encoding, but not all JAXP parsers may support that character encoding.

The JAXP 1.1 API allows applications to plug in different JAXP compatible implementations of parsers or XSLT processors. For example, when an application wants to create a new JAXP DocumentBuilderFactory instance, it calls the staic method DocumentBuilderFactory.newInstance(). This causes a search for the name of a concrete subclass of DocumentBuilderFactory using the following order: The value of a system property like javax.xml.parsers.DocumentBuilderFactory if it exists and is accessible.

In JDK 1.4, there is an Endorsed Standards Override Mechanism which can be used to override the classes in the JDK itself. One way to replace the classes in the JDK with the classes contained in a set of jar files is to place the jar files in some directory, "my-endorsed", and define a system property. For example, to use a newer version of Xalan, place the newer version of xalan.jar in the "my-endorsed" directory and invoke the Java launcher with the -Djava.endorsed.dirs= my-endorsed option.

Use the JAXP 1.2 API to validate instance documents with W3C XML Schema. The JAXP 1.2.0 RI contains two sample programs (DOMEcho and SAXLocalNameCount) that illustrate how to do this. See the JAXP 1.2 specification for more details.

You have concepts problems. JAXP is just standard interfaces for you to use any JAXP compliant Java parser. And xerces is just one of them What you need to do? Move your code to most recent stable build xerces first. Make as less changes as possible. Test your application during the move, don't break your application. If something does not work, fix it. Move to JAXP after that, actually not much left. Search the files for xerces. Change them to its parent interfaces or superclass in JAXP.