- From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com>
- Date: Sat, 26 Feb 2005 11:40:44 -0500
- To: "'ht@cogsci.ed.ac.uk'" <ht@cogsci.ed.ac.uk>
- Cc: "'thompsonbry@users.sourceforge.net'" <thompsonbry@users.sourceforge.net>, "'www-xml-linking-comments@w3.org'" <www-xml-linking-comments@w3.org>, "Bebee, Bradley R." <BRADLEY.R.BEBEE@saic.com>, "'robin.cover@oasis-open.org'" <robin.cover@oasis-open.org>, "'bparsia@isr.umd.edu'" <bparsia@isr.umd.edu>, "Personick, Michael R." <MICHAEL.R.PERSONICK@saic.com>, "'kendall@monkeyfist.com'" <kendall@monkeyfist.com>
Hello, I wanted to report on our XPointer implementation experience. The project is implemented in Java and is hosted on sourceforge at: http://sourceforge.net/projects/cweb Thanks, -bryan XPointer ======== 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? None. 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 language. - 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