There are several ways to do this. The easiest is to use the uberjar release, which can be directly executed on any Java enabled platform. This makes it trivial to test and develop XPointer support in your applications, including server-side XPointer. The uberjar release contains a Java class org.CognitiveWeb.xpointer.XPointerDriver that provides a simple but flexible command line utility that exposes an XPointer processor. The XPointer is provided as a command line argument and the XML resource is read from stdin. The results are written on stdout by default as a set of null-terminated XML fragments. See XPointerDriver in the XPointer JavaDoc for more information.
If you already have a Java application, then it is straight-forward to integrate XPointer support using: org.CognitiveWeb.xpointer.XPointerProcessor You can see an example integration by looking at the XPointerDriver in the source code release.

There is no required configuration for the XPointer Framework. The uberjar command line utility provides some configuration options. Applications configure individual XPointer processors when they obtain an instance from an appropriate XPointerProcessor factory method.

The XPointer integration distributions support shorthand pointers. In addition, they bundle support for at last the following XPointer schemes:
* xmlns()
* element()
* xpath() – This is not a W3C defined XPointer scheme since W3C has not published an XPointer sheme for XPath. The namespace URI for this scheme is http://www.cogweb.org/xml/namespace/xpointer . It provides for addressing XML subresources using a XPath 1.0 expressions.

You can use the XPointer Framework with non-XML resources. This is especially effective when your resource is backed by some kind of a DBMS, or when you want to query a data model, such as RDF, and not the XML syntax of a representation of that data model.
However, please note that the authoratitive interpretation of the fragment identifier is determined by the Internet Media Type. If you want to opt-in for XPointer, then you can always create publish your own Internet Media Type with IANA and specify that it supports the XPointer Framework for some kind of non-XML resource. In this case, you are going to need to declare your own XPointer schemes as well.

Download the latest “cweb-xpointer” release from SourceForge. This project uses Apache Maven and Java 1.4+, so you will need to install those as well. Normally you will also want to download one of the XPointer Framework integrations, such as the xpointer+dom4j or the xpointer+jdom package. These “integration packages” provide support for a specific XML Document model.
The project dependencies are explicitly declared in the Maven POM. This means that Maven can automagically download the required releases of dependent JARs.
There are several release artifacts. The “uberjar” release provides an executable command line utility (see below) and bundles all dependancies (except for Java itself). If you want to integrate into an existing application, then you should use the cweb-xpointer JAR and also download copies of its dependencies. If you are using a Maven project, then this is all very, very easy.

XPointer is set of recommendations developed by the W3C. The core recommendations are the XPointer Framework which provides an extensible addressing behavior for fragment identifiers in XML media types.
XPointer gains its extensibility through the XPointer Framework, which identifies the syntax and processing architecture for XPointer expressions and through an extensible set of XPointer addressing schemes. These schemes, e.g., element() or xpointer(), are actually QNames. The xmlns() scheme makes it possible for an XPointer to declare namespace bindings and thereby use third-party schemes as readily as W3C defined XPointer schemes.

Yes. However, such usage is deprecated, so you should never do it.

Yes.

An XML namespace name is a URI that uniquely identifies the namespace. URIs are used because they are widely understood and well documented. Because people may only allocate URIs under their control, it is easy to ensure that no two XML namespaces are identified by the same URI.

The URI used as an XML namespace name is simply an identifier. It is not guaranteed to point to anything and, in general, it is a bad idea to assume that it does. This point causes a lot of confusion, so we’ll repeat it here:
URIs USED AS XML NAMESPACE NAMES ARE JUST IDENTIFIERS. THEY ARE NOT GUARANTEED TO POINT TO ANYTHING.
While this might be confusing when URLs are used as namespace names, it is obvious when other types of URIs are used as namespace names. For example, the following namespace declaration uses an ISBN URN:
xmlns:xbe=”urn:ISBN:0-7897-2504-5″
and the following namespace declaration uses a UUID URN:
xmlns:foo=”urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6″
Clearly, neither namespace name points to anything on the Web.
NOTE: Namespace URIs that are URLs may point to RDDL documents, although this does not appear to be widely implemented. For details, see the next question.
NOTE: An early version of the W3C’s XML Schemas used namespace URIs to point to an XML Schema document containing the definitions of the element types and attributes named in the namespace. However, this proved very controversial and the idea has been withdrawn.