XPointer - Revision history

Piotr Banski: quick update

2025-07-23T14:49:35Z

quick update

Piotr Banski: /* XPointer syntax */ not sure if the whitespace there was legal

2025-07-22T23:23:06Z

‎XPointer syntax: not sure if the whitespace there was legal

Piotr Banski: "homonymy" was misused here; "homography" would be more precise, but who would bother looking that up

2025-07-22T23:20:46Z

"homonymy" was misused here; "homography" would be more precise, but who would bother looking that up

Jensopetersen: typo (I hope)

2012-05-21T07:42:50Z

typo (I hope)

Stuartyeates: ref

2012-05-11T05:49:24Z

ref

Piotr Banski: /* Structure of the XPointer Framework */ a few details added

2012-05-07T07:56:06Z

‎Structure of the XPointer Framework: a few details added

Piotr Banski: /* Lobbying section */ mainly some formatting

2009-11-06T01:47:27Z

‎Lobbying section: mainly some formatting

Piotr Banski: /* XPointer syntax */ little modifications

2009-11-06T01:35:58Z

‎XPointer syntax: little modifications

Piotr Banski: /* XPointer syntax */

2009-11-03T02:47:26Z

‎XPointer syntax

Piotr Banski: /* XPointer syntax */

2009-11-03T02:44:11Z

‎XPointer syntax

← Older revision		Revision as of 14:49, 23 July 2025
Line 1:		Line 1:
	''For use cases where these techniques might be used, see [[Stand-off use cases]].''		''For use cases where these techniques might be used, see [[Stand-off use cases]].''
		+
		+	'''In lieu of a page update:'''
		+	* See https://github.com/SCDH/tei-xpointer-schemes for a sample implementation of the [https://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATS TEI XPointer schemes].
		+
		+	<br />

	The '''[http://www.w3.org/TR/xptr-framework/ XPointer Framework]''' is a collection of schemes (note: ''schemes'' not ''schemas'') that specify the method for addressing into the XML tree or help in this task. One end of its functionality overlaps with XPath, but the other allows one to address points and ranges inside elements, and this is often precious to us TEI-ers, especially in some [[stand-off markup]] systems or for working with ontologies (RDF may use it). It was initially defined as a companion to [[XLink]] that took care of URI fragment identifiers (the strings placed after the '#' in a URI).		The '''[http://www.w3.org/TR/xptr-framework/ XPointer Framework]''' is a collection of schemes (note: ''schemes'' not ''schemas'') that specify the method for addressing into the XML tree or help in this task. One end of its functionality overlaps with XPath, but the other allows one to address points and ranges inside elements, and this is often precious to us TEI-ers, especially in some [[stand-off markup]] systems or for working with ontologies (RDF may use it). It was initially defined as a companion to [[XLink]] that took care of URI fragment identifiers (the strings placed after the '#' in a URI).

@@ Line 58: / Line 58: @@
 The first alternative allows for addressing by ID, reminiscent of HTML: <code>"resource.xml#ID"</code> (which may also use the element() scheme, as in <code>"resource.xml#element(ID)"</code>), and the other for sequencing schemes, as in the examples below:
-#<code>"resource.xml#xpointer((//p)[1]) element(p1)"</code>
+#<code>"resource.xml#xpointer((//p)[1])element(p1)"</code>
 #<code>"resource.xml#xmlns(tei=<nowiki>http://www.tei-c.org/ns/1.0</nowiki>)xpointer(//tei:p[1])"</code>

@@ Line 42: / Line 42: @@
 </code>
-Notice that '''string-range()''' is mentioned twice in the diagram above. This is because of an unfortunate homonymy that has generated some confusion in the past but, hopefully, will not do so any longer.
+Notice that '''string-range()''' is mentioned twice in the diagram above. This is just a coincidence that has generated some confusion in the past but, hopefully, will not do so any longer.
 The XPointer xpointer() scheme uses [http://www.w3.org/TR/xpath#corelib XPath functions] and adds to them [http://www.w3.org/TR/xptr-xpointer/#xptr-functions several others], which, by entering the inter-character space, are able to cleverly address what no XPath has been able to address before. Among these functions is one called string-range().

@@ Line 3: / Line 3: @@
 The '''[http://www.w3.org/TR/xptr-framework/ XPointer Framework]''' is a collection of schemes (note: ''schemes'' not ''schemas'') that specify the method for addressing into the XML tree or help in this task. One end of its functionality overlaps with XPath, but the other allows one to address points and ranges inside elements, and this is often precious to us TEI-ers, especially in some [[stand-off markup]] systems or for working with ontologies (RDF may use it). It was initially defined as a companion to [[XLink]] that took care of URI fragment identifiers (the strings placed after the '#' in a URI).
-Some of the schemes, e.g. the simplest [http://www.w3.org/TR/xptr-element/ element() scheme], which uses simple tree-traversal syntax, are supported by any decent XML tool nowadays. It is worth pointing out that '''any tool that claims to support XInclude, must support the general conventions of the XPointer Framework and the XPointer element() scheme''' ([http://www.w3.org/TR/xinclude/#application per the XInclude spec]). The "general conventions" of the Framework mean, practically, the possibility of addressing elements by their IDs and the possibility of using multiple schemas in a single pointer (see [[#XPointer syntax|below]]).
+Some of the schemes, e.g. the simplest [http://www.w3.org/TR/xptr-element/ element() scheme], which uses simple tree-traversal syntax, are supported by any decent XML tool nowadays. It is worth pointing out that '''any tool that claims to support XInclude, must support the general conventions of the XPointer Framework and the XPointer element() scheme''' ([http://www.w3.org/TR/xinclude/#application per the XInclude spec]). The "general conventions" of the Framework mean, practically, the possibility of addressing elements by their IDs and the possibility of using multiple schemes in a single pointer (see [[#XPointer syntax|below]]).
 Apart from element(), there is also the [http://www.w3.org/TR/xptr-xmlns/ xmlns() scheme] that does namespace binding, and finally the [http://www.w3.org/TR/xptr-xpointer/ xpointer() scheme] that does an incredible lot of useful things in a very clever way, except it's not supported in full anywhere.

← Older revision		Revision as of 05:49, 11 May 2012
Line 1:		Line 1:
		+	''For use cases where these techniques might be used, see [[Stand-off use cases]].''
		+
	The '''[http://www.w3.org/TR/xptr-framework/ XPointer Framework]''' is a collection of schemes (note: ''schemes'' not ''schemas'') that specify the method for addressing into the XML tree or help in this task. One end of its functionality overlaps with XPath, but the other allows one to address points and ranges inside elements, and this is often precious to us TEI-ers, especially in some [[stand-off markup]] systems or for working with ontologies (RDF may use it). It was initially defined as a companion to [[XLink]] that took care of URI fragment identifiers (the strings placed after the '#' in a URI).		The '''[http://www.w3.org/TR/xptr-framework/ XPointer Framework]''' is a collection of schemes (note: ''schemes'' not ''schemas'') that specify the method for addressing into the XML tree or help in this task. One end of its functionality overlaps with XPath, but the other allows one to address points and ranges inside elements, and this is often precious to us TEI-ers, especially in some [[stand-off markup]] systems or for working with ontologies (RDF may use it). It was initially defined as a companion to [[XLink]] that took care of URI fragment identifiers (the strings placed after the '#' in a URI).

@@ Line 22: / Line 22: @@
                                      /                \
                                     .                  .
-                          W3C schemes            external-party (e.g. TEI) schemes
+                          W3C <span style="color:brown">schemes</span>               external-party (a.o. TEI) <span style="color:brown">schemes</span>
-                        .   .       .                     .      .
+                        .   .       .                     .          .            .
-                       /    |        \                   /        \
+                       /    |        \                   /           |             \
-                      /     |         \                 /          \
+                      /     |         \                 /            |              \
-                     .      .          .               .            .
+                     .      .          .               .             .               .
-                element() xmlns() xpointer()        range() '''[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSSR string-range()]''' ...
+                element() xmlns() xpointer()        range() '''[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSSR string-range()]'''  ...  xpath2()
                                   .       .
                                  /         \
                                 /           \
                                .             .
-                       XPath functions    XPointer functions
+                       XPath 1.0 <span style="color:green">functions</span>    XPointer <span style="color:green">functions</span>
                                              .   .       .
                                             /    |        \
@@ Line 44: / Line 44: @@
 The XPointer xpointer() scheme uses [http://www.w3.org/TR/xpath#corelib XPath functions] and adds to them [http://www.w3.org/TR/xptr-xpointer/#xptr-functions several others], which, by entering the inter-character space, are able to cleverly address what no XPath has been able to address before. Among these functions is one called string-range().
 Thus the difference between the W3C's <code>(location-set) string-range(location-set, string-to-match, offset?, length?)</code> '''function''' and the TEI's <code>(string) string-range(pointer, offset, length?)</code> '''scheme''' is not merely a difference in the definition, but also a difference in the status. There is at least one important consequence of this, worth bearing in mind: '''the status and implementation of TEI's schemes does not directly depend on the status and implementation of the xpointer() scheme'''. Of course, one can hope that the former may piggyback on the latter, from the perspective of software developers.
 == XPointer syntax ==

@@ Line 77: / Line 77: @@
 == Lobbying section ==
 === libxml2 ===
-[http://xmlsoft.org/index.html Libxml2] is the only XML toolkit that has rudimentary support for XPointer's xpointer() schema. In fact, the support is rather bad... but at least it is there and can be fixed and extended if the need for it can be demonstrated. (The trick with diploma works may also work here -- there is a separate XPointer module that the student can concentrate on.)
+[http://xmlsoft.org/index.html Libxml2] is to my knowledge the only XML toolkit that has rudimentary support for XPointer's xpointer() schema. In fact, the support is rather bad... but at least it is there and can be fixed and extended if the need for it can be demonstrated. (The trick with diploma works may also work here -- there is a separate XPointer module that the student can concentrate on, possibly having an eye on what is common in handling the xpointer() scheme and the TEI-defined schemes)
 In fact, the TEI doesn't need the xpointer() scheme to be supported in xmllint (libxml2's parser) -- it just needs the general XPointer Framework to work (see the Addendum below for explanation).
@@ Line 86: / Line 88: @@
 Have to extract some bits from this fragment still.
 <tt>
 I searched for freely-available free-standing XPointer-aware tools
@@ Line 100: / Line 103: @@
 some links as starters:
-"internal error, xpointer.c:2409" when using string-range()
+;"internal error, xpointer.c<nowiki>:</nowiki>2409" when using string-range():
-https://bugzilla.gnome.org/show_bug.cgi?id=562541
+:https://bugzilla.gnome.org/show_bug.cgi?id=562541
-Xpointer range-to function loses the end-point children
+;Xpointer range-to function loses the end-point children:
-https://bugzilla.gnome.org/show_bug.cgi?id=306081
+:https://bugzilla.gnome.org/show_bug.cgi?id=306081
-buggy range() XPointer function
+;buggy range() XPointer function:
-https://bugzilla.gnome.org/show_bug.cgi?id=584219
+:https://bugzilla.gnome.org/show_bug.cgi?id=584219
-buggy string-range() XPointer function
+;buggy string-range() XPointer function:
-https://bugzilla.gnome.org/show_bug.cgi?id=583442
+:https://bugzilla.gnome.org/show_bug.cgi?id=583442
@@ Line 117: / Line 120: @@
 while, until this bug got fixed:
-unrecognized XPointer schemes are not skipped silently
+;unrecognized XPointer schemes are not skipped silently:
-https://bugzilla.gnome.org/show_bug.cgi?id=563562
+:https://bugzilla.gnome.org/show_bug.cgi?id=563562
 (so there is a light...)

@@ Line 54: / Line 54: @@
 SchemeBased	  ::=   	PointerPart+</pre>
-The first alternative allows for things like <code>"resource.html#ID"</code> (which may also be used as <code>"resource.html#element(ID)"</code>), and the other for sequencing schemes, as in the examples below:
+The first alternative allows for addressing by ID, reminiscent of HTML: <code>"resource.xml#ID"</code> (which may also use the element() scheme, as in <code>"resource.xml#element(ID)"</code>), and the other for sequencing schemes, as in the examples below:
-#<code>"resource.html#xpointer((//p)[1]) element(p1)"</code>
+#<code>"resource.xml#xpointer((//p)[1]) element(p1)"</code>
-#<code>"resource.html#xmlns(tei=<nowiki>http://www.tei-c.org/ns/1.0</nowiki>)xpointer(//tei:p[1])"</code>
+#<code>"resource.xml#xmlns(tei=<nowiki>http://www.tei-c.org/ns/1.0</nowiki>)xpointer(//tei:p[1])"</code>
 The XPointer processor must evaluate such sequences from left to right and stop whenever it succeeds in making a match. This means that in the first case, ''if the scheme is recognized'', the processor tries to match the first of all <p&gt; elements that can be found in the document, and if it does not succeed, it moves to the second scheme and looks for the first element identified by the ID "p1". Notice that this setup makes it '''possible for us to use TEI-defined schemes with any processor, provided that we provide some kind of fallback''' as the last scheme. Does that buy us much? Hardly, but it's a step forward until the processor starts recognizing TEI schemes.
@@ Line 64: / Line 64: @@
-Note one more thing: the fact that the non-W3C schemes xpath1() and smlxpath1() are supported and in use, makes it more likely for us to get the developers to plug in TEI-defined schemes into their tools.
+The fact that the non-W3C schemes xpath1() and smlxpath1() are supported and in use ('''note:''' what are the tools that support them? -- need to find that out), makes it more likely for us to get the developers to plug in TEI-defined schemes into their tools. Of course these schemes have to be coded first, but that was obvious from the beginning.
 Link to [[Xpath12match.xslt]]

@@ Line 66: / Line 66: @@
 Note one more thing: the fact that the non-W3C schemes xpath1() and smlxpath1() are supported and in use, makes it more likely for us to get the developers to plug in TEI-defined schemes into their tools.
 ----
@@ Line 72: / Line 73: @@
 What follows is a mess for now.
 == Lobbying section ==