Many thanks to everyone who responded.
Some quick responses and a follow up.
The error is not caused by the presence of ":" per se but its presence
in the absence of either a full path or a leading hash tag. There are
many ways of "fooling" the jing validation of the relaxng schema
(@Martin, @Syd, et alii), but I clearly did not do my homework on what
qualifies as a URI, and what should be in the first position on
string-range(). Thanks to all for the corrections and the history.
In general, I am aware that support for such mechanisms is sketchy, but
in my particular use case, where each word is in its own w element, it
was envisaging "translating" the notation to an xslt 2.0/xpath 2.0
substring() function. But the broader discussion indicates a requirement
of better and more clearly defined pointing in my project.
In a somewhat different context, the suggestion of a developer who
worked with my project a year or two ago was that we envision the <w>s
as made up of *virtual* <c>s, that can be actualized as needed:
<w xml:id="abc">word</w> becomes:
Then, instead of <m>, then, we use <span> and @from and @to indicate
range. (Single letter ranges: use identical values for @from and @to? or
Is this any better from a best practices point of view?
As a practical matter, where does one document this assumption about the
encoding of the <w>?
All best, and many thanks,
On 2/24/2015 4:23 AM, Piotr Bański wrote:
> 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).