-----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-----