Mis-information on XPath - my bad

[Patrick Durusau <patrick@durusau.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings!

I'm afraid that I gave the wrong impression about XPath information
for change tracking in my earlier post showing the various paths in
the ODF standard's content.xml.

For example, in Svante's test document, he used an application (I
won't say its name), which reported an XPath of:

*****
/office:document-content/office:body/office:text/text:list/text:list-ite
m/text:list/text:list-item/text:list/text:list-item/text:list/text:list-
item/text:list/text:list-item/text:list/text:list-item/text:list/text:li
st-item/text:list/text:list-item/text:list/text:list-item[1]/text:p/text
:span
*****

If that is what Camilla objects to, I'm on her side. That's just way
too verbose and ugly.

*However*

After realizing that what Svante's wants to point to is a counting of
the text:p elements, then the span element following the ninth p
element, I produced the following XPath statement:

(doc("content.xml")//text:p)[9]/text:span[1]

I show the entire XQuery so you can see the opening "(" in front of doc.

What this means is to read content.xml and then count the text:p
elements, wherever they are found "//", count to the ninth [9] p:text
element and then select the first [1], text:span element. The content
of which is A.

Since the equivalent of (doc("content.xml") is going to be supplied by
the application, the recorded XPath to be exchanged would look like:

//text:p[9]/text:span[1]

and you could default the namespaces:

//p[9]/span[1]

Assuming you document that we are reading text:p as a counted
"component" (the parens around doc to the //) - then this notation
isn't all that different from Svante's.

Well, one substantial difference from Svante's is that every
conformant XPath application (such as XSLT and XQuery engines) will
today give you the same result. An existing base of applications that
already use and understand this notation.

Oh, that was my second mistake in talking about XPath. I was never
suggesting all of XPath but only the descendant axis and then only
with positional predicates "[0-9]".

Which an application could further simplify if it chooses to do so
internally but externally it should still serialize to XPath.

My bad.

I need to look more closely at the XQuery Update language, which I
like, except for its implication that the document instance is in fact
being changed. Necessary more than 25 years ago when the markup
adventure started but its time we stop pretending we are have to
operate in the lower 640K of memory.

Hope everyone is having a great week!

Patrick

PS:

If you want to test the XQuery I wrote:

*****
declare  namespace text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
;

for $text in (doc("content.xml")//text:p)[9]/text:span[1]
return string($text)
*****

PPS: Does anyone have a list of all (most of the projects using ODF)?

I ask because SourceForge reports 53 and Github says 216. Other places
I should be looking?

I did see joeffice.org the other day but it uses OOXML. If change
tracking cuts across the formats, might be interesting to ping them.



- -- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWqShSAAoJEFPGsgi3MgycDAQQAKQwxenfPVlhT4T4VK6bBRgE
E/dXMFWF9/7flJ6LMXZLp2YfA5nqCGNguqFKx5hJRnNo9EoV2d4KUl4hMpGunHIi
a1jyEDpzKTmZYuCqN9DZOdXRgHZ8Kin3/Pgh2/EYmKV0lhd4m+nWEwMpqF8W+fE2
9SjU/lDgReNwLMSC1SUdv9Sd3x0UCqXwSKo9Cgit62NtxkjBMDiRZSG39HN5cLDJ
u8Cc6zqIXKgHM+kMYkSWQwdEj0JGChwPnSXKdQUQkmX0xhuDYnFIaomcSRwCrbRr
N0C1n5yNiKI+e8dTWeWsrLefAoryANjxGenPq82lInn+v7Yt5hpWybext2vHqs7u
BA/4fqEcz+XFH6Rdwkd01Di127PeowraXDg/WyxS7Rs85lmpFgTNYxy/VRa5roDT
3bWn3Rr7IqnX0aWfcHqohdk3mY2SEGYlyEOXE2YtqHj41k9vqGnmdCDPtKgf8yNQ
/uuTlB64fUGAJ0ffFtBpdAHETQ6QqVdfHOQdGTzECCnbWjgKmCnRKoBsAw1LpiDc
OGnZBrWJUENZh0FuIjFEchiwO5fssBSWFTEFIpP4pwdfG6x7hihQVEDtZFViHwUI
UpgB0Vw7bpR8w2jq91cSmoWBU4nTPe7cy5Ixv1/lxysO4W/zrOarvGZMb3AQHhVW
3WD7PZz3cvLXzgEwlvxc
=2ZiN
-----END PGP SIGNATURE-----