Syd Bauman writes:
> 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.
You're most welcome. XPointer support appears undertested, but still,
the tool is almost ready to use for the purposes of TEI.
> 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
You are apparently right, and this situation IS weird. Their
registration policy says that "anyone can submit a registration request
on a 'first come, first served' basis," except that they forgot to
register their own schemes... or at least to check for name conflicts.
And indeed, 'namespaces' for schemes come at most in the form of
numerical suffixes (xpath1, xpath2).
> But you mention a W3C draft that apparently defines (a different)
> string-range() xpointer scheme -- can you point us to this document?
which is the draft part of the entire Framework (=recommendation):
The draft is not mentioned at the beginning of the recommendation, but see:
And it is the schemes from the draft that they write books about -- cf.
e.g. "XPath and XPointer" by John E. Simpson. O'Reilly, 2002.
> 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.
It hasn't been used much -- it only produced some 100 emails and 6 bug
reports, one of which looks bad and still needs to be addressed:
Daniel Veillard appears to be very responsive to users though, which is
a good sign.
A promising way out seems to be to a) rename TEI schemes and b) either
supply a patch to libxml to handle them, or, if this is within the
Consortium's prerogatives, make Daniel Veillard an offer he will not
I mention Daniel and libxml because this path is almost complete -- all
the infrastructure is there -- all that is needed is plugging in the
required functionality and (stand-)off we go... :-) And xmllint is a
good fast parser available for all the popular platforms.
Call the schemes, say, string-span() and span(), and you have nice
generic names that everyone can use, and they are fairly intuitive,