I think there may be problems in the way that the cfg:set macro
component evaluates the XPath expression passed into the 'expression'
attribute. This email provides a brief analysis of one indicator of the
problem.
The following configuration snippet is a nifty, quick-and-dirty XPath
search command:
---
<cfg:command name="doXPathSearch">
<cfg:macro>
<cfg:sequence>
<cfg:command name="prompt"
parameter="Question 'XPath search string:'
//element"/>
<cfg:set variable="selectedNode" expression="%_"/>
</cfg:sequence>
</cfg:macro>
</cfg:command>
---
It works... for some expressions. If you plug the above into a DocBook
configuration (with some way to call it, like a menu item), you can
experiment with it on DocBook files. For example, consider the
following DocBook document:
---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd";>
<article>
<title>Test Article</title>
<itemizedlist>
<listitem id="top-list1">
<para>A top level element</para>
<itemizedlist>
<listitem id="bottom-list1">
<para>First item in a sublist</para>
</listitem>
<listitem id="bottom-list2">
<para>Second item in a sublist</para>
</listitem>
<listitem id="bottom-list3">
<para>Third item in a sublist</para>
</listitem>
</itemizedlist>
</listitem>
<listitem id="top-list2">
<para>Second top-level element</para>
</listitem>
<listitem id="top-list3">
<para>Third top-level element</para>
</listitem>
</itemizedlist>
</article>
---
Run the doXPathSearch command, and enter '//listitem' at the prompt.
Looking good, this selects the first listitem (with an id of
'top-list1') in the document (in document order), as you would expect.
Now how about '//listitem[2]'? This actually selects the listitem with
an id of 'bottom-list2', which is the *third* listitem in document
order. I would have expected it to select the listitem with an id of
'bottom-list1'. Is there something "interesting" going on with the
XPath evaluation here? I've also seen some other very odd XPath
behavior from this same command, but for which it is harder to provide a
concise example.
And now I'd like to go off on a tangent, if noone minds. I have been
wanting a structural search feature for as long as I've been using the
XMLmind XML Editor (XXE). I finally decided to take the plunge and code
one up as a Java plugin using the XXE Command API, when I stumbled
across these new XPath evaluation mechanisms. They must be relatively
new, because I know that I hadn't seen them when perusing the
documentation a short while ago. Anyway, I think they will be very fun
toys for building more powerful configurations.
That said, I may end up writing my structural search utility as a Java
plugin anyway, because I want it to have some state (so that you can
"search again") and because I may want it to have a more refined user
interface.
Take care,
John L. Clark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20050524/e7740025/attachment.sig
