Cool XPointers Do Change?

I missed one thing out on my list of things to evaluate: (URIs with)
FragmentIDs, and especially XPointers. IMO, the more I think about
XPointer, the less consistent that I feel it is with the rest of Web
architecture. In fact, I only became aware of it after continual
nagging from Aaron, and then actually trying to implement it in our
(consistent) EARL-world.

I would like to address a note to the XML-Linking group, but if I am
to do it on behalf of the ER WG rather than myself, we obviously all
need to discuss it, and the Chair needs to have the final say. Quoted
sections of this document come from the CR version of XPointer [1].
Comments period ends on 4 March 2002, but I hope that we can address
this very quickly.

> In the course of implementing the XPointer design as
> presented herein, were any aspects or subparts
> encountered which caused significant implementation
> difficulty?

One core principle of the Web is that URIs and URI references should
generally apply to the "same thing". There is a notion of persistence
that makes the Web work - the binding of a URI to a resource in
particular is persistent. The relevent RFCs (2396 and 2616) are very
clear on how the Web should work. For the Evaluation And Report
Language, we are being careful to ensure that it fits in with Web
archtecture. We also have a need to be able to point into the XML
document tree in order to make assertion about it. Although we felt
that XPointer would be perfect for this, we have found that it
conflicts terribly with Web architecture in general.

The EARL model contains a certain structural entity called the "Test
Subject". This is simply the resource (in the RDF sense of the word)
which is being evaluated. To be clear about what is identified, we
have a property that gives a relationship between a representation,
and the resource. This breaks down if a fragment identifier points to
a specific set of bytes in a page.

The notion of an "ID" (or "name" in HTML) is very useful, because it
allows you to define relevent pieces of the document; but they still
have a certain level of abstraction. It is still true that IDs can and
should be persistent. This is not true for XPointers; unless a
resource has only one corresponding representation, and does not allow
content nor perhaps even language negotiation. The fear is that people
want something much looser... XPointer *will* be abused.

To state this problem in alternate terms, consider an example. There
is a document available in plain text, and as XML. The XML version can
obviously have its constituent parts identified by a series of
XPointers. However, if someone uses (for example):-

   http://example.org/#xpointer(id("myId")/elem[5])

Does the group expect that same XPointer to apply for the text
document too? Of course not, and this means that using XPointer on a
resource prevents conneg in any way shape or form. It also prevents
modification of the document, unless you start stating that
FragmentIDs are not persistent, which would violate a Web axiom.

> If so, would eliminating some or all of the
> difficult-to-implement aspects or subparts leave a
> coherent design still useful for your needs?

We *do* need a method to point into representations of resources that
use the generic XML media type (anything with the "+xml" suffix). We
do not believe that a fragment identifier is the correct solution. One
possible solution is to use an XPointer as a predicate relationship,
thus:-

   [ earl:reprOf <http://example.org/>;
     :date "2001-10-17"; :format "text/xml";
      :XPointer "xpointer(id("toc")/li[3])" ] .

The difficult-to-implement part is simply in defining XPointer to be
the standard XML FragmentID syntax.

> Does your implementation experience suggest reasons
> why the XPointer language as defined herein should not
> be recommended to the IETF as the fragment identifier
> language for resources of type text/xml etc.?

Yes, see above for details. The fear is that XPointer will be abused.
Another point to note is that XPointer (in general) conflicts with
fragment IDs in RDF. This is a highly relevent point to us because
EARL is an application of RDF; the schemata and so forth are RDF too.
A FragmentID on a document using the (yet-to-be-registered) XML RDF
MIME type will necessarily identify the concept that the RDF document
*says* it identifies. It does not identify a part of the document
tree, and yet XPointer says that it does.

In summary, XPointer is an excellent and vehemently useful idea. The
work conducted by the XML linking group has provided us with a glimmer
of hope in being able to identify parts of specific XML documents.
However, implementing XPointer as a FragmentID is not consistent with
Web architecture, and XPointer should not go to recommendation
mandating that behaviour.

[1] http://www.w3.org/TR/2001/CR-xptr-20010911/

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Sunday, 9 December 2001 19:12:16 UTC