Menu
▾
▴
#405 XPointer schemes may not nest, but see ch. 16
open
1(low)
2013-11-13
2012-05-02
No
Please verify:
1. this is XPointer syntax: http://www.w3.org/TR/xptr-framework/#syntax
2. the TEI schemes defined in chapter 16 are meant to be well-behaved XPointer schemes
3. XPointer schemes may be chained, but may not be nested [everything depends on this assumption, so please attack or confirm]
4. In ch. 16, we have examples such as:
a. string-range(element(/1), 84,109)
b. range(xpath1(id(par1)//emph),xpath1(id(par2)//emph))
with TEI-defined schemes containing W3C-defined schemes in (a), and TEI-defined schemes containing third-party-registered schemes in (b).
Discussion
By way of further explanation: id() is not a scheme but a function, so it can be nested all right.
I tried to tease apart the two unfortunately homonymous string-range()s here:
http://wiki.tei-c.org/index.php/XPointer
I once suggested renaming the TEI's scheme to string-span(), to avoid the ambiguity. Maybe we could still consider that, given that these schemes haven't been used in any other form but as informal shorthand notations?
+100 from me for renaming TEI's string-range to something else (string-span sounds good). This has seriously confused me in the past.
The tricky trick concerning assumption 3 is that syntactically, there is nothing wrong with having something like
scheme( name1(), something)
in particular, "name1" can be a name of another scheme, e.g. "xpath1" or "xpointer" (it can also be "a:bc:d", but that's another thing, and not so relevant to the issue at hand).
So one could say, why, the XPointer Framework doesn't preclude schemes which take other schemes as arguments, so the Guidelines are OK ("what's not explicitly prohibited is permitted").
To which my answer would be: but the TEI string-range() is defined as
string-range(fragmentIdentifier, offset [, length]) [16.2.4.5]
and, on the assumption that "fragmentIdentifier" is an actual datatype returned by barename pointers or XPointer schemes, it implies that you can put any XPointer scheme there.
Next, the Guidelines say "The other five schemes overlap in functionality with a W3C draft specification known as the XPointer scheme draft, but are individually much simpler." (16.2.4.1). Given that these schemes are defined in such a way that they take the existing XPointer schemes as arguments, I see no increase in simplicity here, quite on the contrary. A scheme that presupposes other schemes as arguments may not be simpler than those individual schemes. Additionally, it involves evaluation of XPointer schemes in contexts where *no* W3C specification expects them (= as arguments to other schemes). No simplicity there at all.
Just to mention: it would be quite unfortunate to rename string-range() now that ISO MAF has been sent out for editing at ISO central secretariat. This should have been raised within the SOM group when I suggested the syntax introduced in the document.
Assigning to GB, Incorporate this ticket into the StandOff Markup discussion and report back to Council.
Assigning to GB, Incorporate this ticket into the StandOff Markup discussion and report back to Council.
The draft rewrite of the XPointer section completely does away with the idea of nested XPointers. I'm inclined to push ahead with the completion of that rather than spend time patching broken examples in the existing XPointer section, since (as Gabby points out) to fix the examples now might give the impression that the existing recommendation is viable.
Assigning this ticket to Hugh, who has more control over the XPointer process now that he is on Council. If he feels that there is Council consensus to ignore the existing Pointer schemes in favour of the new proposal (or some other complete revision) he should close this ticket with a comment to that effect.
Council 2013-11-13: While HC works on the broader revision of the XPointer section of the Guidelines, we think we should assign this particular ticket, which appears to be a corrigible error, to SB, who can just make an interim fix if he determines that the Guidelines prose and/or examples are technically wrong.