Dear Marco (and Others),
Marco Petris writes:
> I had a similar question last month:
> There seems to be no tools that fully supports w3c-xpointer drafts or
> TEI-extensions, see the answers to my question provided by Syd Bauman.
Thanks, I saw your query, but hoped that unlike in your case, where the
spec forbids the simultaneous use of @parse="text" and @xpointer,
someone might have experimented with string-range()s targetting the
content of XML elements, and found or created a tool that is able to
resolve such pointers -- because the spec allows that and even the
Guidelines provide examples of exactly such cases.
For now, the project I mentioned will apparently need to process
xpointer()s with e.g. Perl, so I would be happy to hear of some previous
attempts to do so, even if they have failed. (The simpler cases should
be fairly straightforwardly doable with XSLT, it now occurs to me,
though I'm not sure about the efficiency in the context of really large
To change the focus a little, let me turn to ch. 16 of the Guidelines --
I'm not really sure that the reader gets enough warning in this chapter
that using xpointer() or xpath1() won't get them far into stand-off
At the end of 22.214.171.124, it says, "At the time of this writing, there is
no current or scheduled activity at the W3C towards revising [XPointer
scheme *draft*] or issuing it as a recommendation." But this alone
doesn't say that there are no tools to handle xpointer() -- and it has
happened in the history of XML that tools moved on with each new version
of drafts. The more so that the actual *recommendation* for the XPointer
Framework provides examples of string-range()s and their kin.
Next, section 16.9.2 rightly mentions that XInclude is only required to
support the element() scheme, but then devotes lots of space to examples
of xpointer(). One might infer from the presence of these examples and
discussion that there may exist tools that provide more than what is
minimally required by the spec.
Now let me stress: I like these examples, and I appreciate them. I'm
very happy they are there. But it seems likely for some readers to
assume that if so much place is devoted to discussing and illustrating
some technology, the technology is well-established and tools exist for
it. All I'm suggesting is an explicit warning that this very bit of
technology is still a matter of the future -- after all, these examples
from the Guidelines do not validate for TEI DTDs that aren't
XInclude-aware, do they? (because inclusion fails and then the parser
complains about foreign markup, namely <xi:include/>).
There is one more fragment that I find a bit imprecise, at the beginning
of section 16.9.5:
"When the source text is plain text[,] the overall form of the XPointer
pointing to it is of minimal importance."
If I understand the spec correctly, when the source text is plain text,
you simply can't use XPointer at all, because you are not allowed to use
@xpointer. Perhaps this sentence could be reformulated or removed?