I am so tickled to hear that the XInclude processing in xmllint
(i.e., libxml2) handles TEI XPointer schemes. I've made use of its
XInclude processing for many years, but never knew it could handle
any XPointer schemes. Thank you *so* much for pointing this out.
However, having taken a quick look, the only conclusion I can come to
is that while libxml2 is implementing xpointer schemes in its
XInclude processor (yay!), the string-range() scheme it has
implemented is *not* the TEI string-range() scheme.
This strikes me as a bit of a problem. To my knowledge there exists
no namespaces for XPointer schemes, rather the mechanism for
avoidance of name collisions like this is the W3C XPointer Scheme
registry. The string-range() scheme registered there is the TEI
scheme defined in P5. (see
But you mention a W3C draft that apparently defines (a different)
string-range() xpointer scheme -- can you point us to this document?
BTW, on poking around I easily found that documentation for the
libxml2 API for XPointer comes with libxml2, although at the moment I
can't make head or tails of it. I also found that XPointer support
has been in libxml2 since 2002.
> Thank you very much for the suggestion, I will put it into the wiki
> when I get around to writing a page about stand-off markup, so that
> others may use it too. Although the servlet didn't work for me, it
> still looks like a good foundation, judging from the description.
> And now, tadammm, let me tell you that I have found a promising
> implementation of xpointer(), in one of the standard parsers:
> xmllint! :-)
> Below, I include a little test case that can be a beginning for
> exploring this implementation. A few corrections in chapter 16 of
> the Guidelines are in order, because some of the examples there
> don't follow the W3C draft (which admittedly seems a bit unclear at
> places) -- for example, string-range() takes two obligatory
> arguments, rather than one, as the Guidelines suggest (the string
> must be there, even if it's empty). OTOH, range() only takes one
> argument at most.