Styler conditions: xpath vs attribute test on performance

[stephen_cuzner]

We have multiple doctypes with different top level tags but every top level tag has identical attributes that control gentext for specific elements. For example:

<handbook role="template">...<name>[...]</name>...</handbook>

<handbook role="document">...<name>...</name>...</handbook>

<brochure role="template">...<name>[...]</name>...</brochure>

<brochure role="document">...<name>...</name>...</brochure>

Where the [ and ] in the template lines are gentext.

I can implement the condition on the name element as two attribute tests of ancestor = handbook, attribute = role, comparison = template andancestor = brochure, attribute = role, comparison = template and connect those two attribute tests with an OR boolean, but I could also implement as a more concise singlexpath rule of /*[role="template"]. Also note that I have many more doctypes other than handbook and brochure, so the maintenance becomes difficult as we add new doctypes and have to go back and add the new attribute tests.

i also know that xpath is not all that fast in Arbortext, at least in some situations. So is there any significant performance penalty by using the xpath test vs the attribute tests as described?

Thanks,

Steve

[ClayHelberg]

Hi Steve--



In my experience, XPath performance is decent in Styler, as long as you
are sensible in how you write your XPath expressions. As you probably
know, there are many different ways to express a particular set of nodes
in XPath, and they can vary dramatically in terms of performance. I
think your example should work fine. However, if you were to use
something with double-slashes in it (for example,
"//*[@role='template']"), that could definitely slow things down. So,
make sure your XPath expressions are as constrained as possible, and you
should be fine using it in Styler.



--Clay



Clay Helberg

Senior Consultant



TerraXML

1380 Forest Park Circle, Suite 100

Lafayette, CO 80027

[stephen_cuzner]

Thanks, Clay, that's what I was thinking. I believe we were using xpath in past versions of the //*[@role='template'] variety and that caused performance issues which lead to a wholesale rejection of xpath in this shop. The other potential problem I see is that the //* construct should return a node-list rather that a specific node, so the composition engine would have to take the first node from the node-list and throw away the rest. I would assume that the node-list would be in document order which would still return the root, but if the root didn't have role specified you could get all sorts of unexpected results.

Steve