Parts of the XPointer scheme are supported indeed, though e.g. Firefox
threw most of it away -- first element(), then xpath1(). I remember
getting hit by the elimination of element() at some conference
presentation, before which I had upgraded from FF 2.x to 3.x...
Currently xmllint supports some bits, though sometimes with bugs in edge
cases. Back when I was still enthusiastic about this technology moving
forward, I started a page in TEI wiki on that:
It lists some basic info, hopefully helps understand the difference
between the XPointer string-range() function and the TEI string-range()
scheme, and lists a few bug reports to libxml2. Some of them I even
managed to push along back then.
And one mustn't forget that the @xpointer attribute in XInclude does not
guarantee XPointer support, BUT I was able to create some corpus files
that could actually work with it, witness the (largish!)
If you parsed that with xmllint and inclusions enabled, you would end up
with the proper fragments of the base texts appropriately inserted.
Unfortunately, the documentation is gone with Sourceforge's switch away
from Mediawiki, I am not even sure if I have a dump of it.
On 24/02/15 04:48, Conal Tuohy wrote:
> Thanks Hugh! And sorry ... my earlier email was confused and a bit
> I guess my main point is this: there are parts of the XPointer framework
> that are better supported than others, and if people use the
> better-supported parts in their encodings, then their standoff markup
> can processed much more simply.
> Currently, the TEI's XPointer schemes (like string-range) are in the
> "not well supported" category. By using different schemes, though,
> similar meanings could be encoded, I think, and be made to work in
> practice, with a variety of existing tools, without the need for custom
> On 24 February 2015 at 12:24, Hugh Cayless <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
> I’ve been working on implementations on-and-off since rewriting the
> TEI Pointers section of the Guidelines to make. It’s slow going,
> implementation that works with TEI Boilerplate and I’m confident
> that an XSLT-based version is possible, as long as it’s running in
> an environment where XPath evaluation is possible.
> XPointer is more-or-less dead from an implementation standpoint,
> isn’t it? I think there’s still value in having a notation that can
> handle pointing at things that aren’t elements though.
>> On Feb 23, 2015, at 20:50 , Conal Tuohy <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>> Leaving aside the issues of how to abbreviate a URI with a prefix,
>> and what is the correct syntax for using TEI "string-range"
>> pointers, I wanted to raise a question about actual software
>> implementations of string-range and similar stand-off schemes. I
>> would guess that actual support is very limited, and that such
>> URIs "won't resolve without help", as Hugh says.
>> It seems to me, from a pragmatic point of view, that it might be
>> time to migrate from the TEI's own pointer schemes (such as
>> string-range) to the XPointer framework, and use the XPointer
>> schemes which were derived from the TEI pointer schemes. The
>> reason to do this would be to improve the level of software
>> support, and make it easier to actually resolve these pointers in
>> practice. XPointer is relatively well supported because it is part
>> of XInclude.
>> For example, in XPointer, an equivalent reference would be:
>> On 24 February 2015 at 11:08, Hugh Cayless <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>> String-range() takes the place of a fragment identifier in a
>> URI, so it cannot, itself, reference another document. The URI
>> part before the hash has to reference the other document.
>> String-range() takes an IDREF or an XPath expression returning
>> an element or text node. So #string-range(abc,0,4) would point
>> at an element with @xml:id="abc" in the same document.
>> wd:document#string-range(abc,0,4) is a valid URI, though
>> obviously not an HTTP(S) URI, so it won’t resolve without
>> help, but you could certainly do something like that if you
>> > On Feb 23, 2015, at 17:25 , Syd Bauman
>> <[log in to unmask] <mailto:[log in to unmask]>>
>> >> corresp="#string-range(wd:abc,0,4)
>> > Hey, Martin. I'm not so sure ... the definition of the first
>> > to string-range is "IDREF | XPATH". Surely "wd:abc" is not
>> an IDREF,
>> > and I don't see how it is an XPath, either.
>> > But Hayim wants to point to something in another document, so
>> > starting his data.pointer with a hash is at best
>> > I'm thinking maybe something like
>> > corresp="wd:document#string-range(id('abc'),0,4)"
>> > (of course that's not much better than the original
>> > corresp="string-range( ../folder/text.xml#abc,0,4)"
>> > but at least Hayim can decide which he likes better).