XPointer implementation experience.


I wanted to report on our XPointer implementation experience.  The
project is implemented in Java and is hosted on sourceforge at:




How does the technology use XPointer?

The xpointer package implements the XPointer Framework, shorthand
pointers, the element() scheme, the xmlns() scheme and a non-W3C
defined xpath() scheme in a non-default namespace.  There is full
support for extension for third party pointer part processors for both
shorthand and scheme-based processors.  The implementation is in Java.
It is currently divided into three modules:

1. xpointer - an concrete implemenation of the XPointer Framework and
   an abstract implementation of the bare name scheme and the various
   supported pointer schemes (element, xpath1).  This module supports
   the registration and integration of additional XPointer schemes.
   It also supports a request-response processing module designed to
   decouple the XPointer Framework from the assumption that it is
   processing a local XML resource.  This makes it possible both to
   efficiently process local XML resources, but to also write XPointer
   schemes that operate across RDF repositories or relational data
   that is never materialized as XML.

2. xpointer-dom4j - an integration of the XPointer Framework with the
   dom4j package (this is the first release of this module, but the
   functionality was previously integrated in the xpointer module).

3. xpointer-jdom - an integration of the XPointer Framework with the
   jdom package (this is the first release of this module).

It is quite easy to add support for other XML DOMs.  For example, the
jdom integration took one day.

There has also been significiant related effort to develop the notion
of "Server-Side XPointer" in which an HTTP user agent delegates the
evaluation of the XPointer expression to an HTTP server by placing a
copy of the XPointer expression within an HTTP "Range" header.  This
is part of an exploration of fine-grained addressing and direct
manipulation of subresources using the REST architectural style.

Does (or will) the technology claim XPointer conformance?

Yes. The only known non-conformance issue are addressing external
parsed entities and support for schema-determined attribute-IDness and
element-IDness (the current integrations (dom4j and jdom) do not make
use of XML Schema information).

Please provide details about the parts of XLink implemented.
- Bare names: Yes, in the shorthand pointer processor.
- Child sequences: Yes, in the element() scheme.
- id() function: No.
- Full XPath: Yes, in the non-W3C xpath() scheme.
- range-to: No.
- string-range: No.
- Namespace support: Yes, in the XPointer Framework implementation.
- In programming API: Yes.
- In user interface: No.
   - Selecting/showing multiple non-contiguous ranges
- Any other comments/details?

Support for the xpointer() working draft is being considered.  Current
efforts are focused on support for scheme-based pointers for
identifying subresources in RDF and topic map data.  We are also
interested in exploring the notion of both robust out of line anchors
(ala Phelps and Wilenski) and providing a means for servers to produce
opaque identifiers that can be used to identify the same subresources
and an XPointer expression by clients that are not XPointer-aware (a
client identifies the sub-resource(s) of interest using an XPointer
scheme and the server mints if necessary and discloses an opaque URI
that may be used to interact with the identified resource(s)).

Overall, the extensibility of the XPointer Framework has been the most
interesting and powerful feature.  We have developed non-W3C schemes
for xpath(), RDF, and are exploring schemes for RSS/Atom.

It would be good if the W3C would standardize an xpath() scheme.
Today many different XML languages use XPath expressions without using
XPointer.  This means that they are limited to within document linking
expressions.  If the W3C were to standarize an xpath() scheme this
would make it easier for XML language developers to opt-in for the
extensibile XPointer Framework and support extra-document linking.

What difficulties did you discover in using the XPointer specification?


What difficulties did you discover in implementing XPointer?

- The xpointer() scheme is difficult to implement since it requires a
  finer access to the XML document that is supported by the XPath

- The addressing of external parsed entities has been difficult to
  implement since many XML processors do not report this information
  through their APIs.

Received on Saturday, 26 February 2005 16:40:57 UTC