Freelance software grandad
software created
extended or repaired
Follow me on Mastodon
Applications, Libraries, Code
Talks & Presentations
Revisiting position matches at the moment. I've described how position matches need to be written, and the code works and works well.
Except when it doesn't. It actually fails for the less common cases, and it took me a little while to work out why.
Here's the pattern from the test case that showed the problem
foo[@att1='c'][2]
It wants to match the second node in the set of foo elements with an att1 attribute containing 'c'.
Arabica rewriting finds the positional predicate and applies its incorrect magic. The rewritten pattern is equivalent to
foo[2][@att1='c']
which picks out the second foo node if it has an att1 attribute containing 'c'. The difference isn't immediately clear, even when you have the both the incorrect output and the expected output sitting in front of you.
My small crumb of comfort is that if you do want foo[2][@att1='c']
, Arabica does do the right thing. That gave me the clue. Arabica implements XSLT match patterns by rewriting them as XPath expressions.
foo[2][@att1='c']
is rewritten as an XPath along the lines of
self::foo[. = parent::*/foo[2]][@att1='c']
My faulty rewriting of
foo[@att1='c'][2]
was
self::foo[@att1='c'][. = parent::*/foo[2]]
which you should be able to see is logically identical to the above. What I need is
self::foo[. = parent::*/foo[@att='c'][2]]
I had to work quite hard to see that this is what it should be, despite being pretty familiar with XPath and XSLT use and implementation. It's only been part of my working toolkit for the last 8 years or so, after all. When rewriting a positional match, any preceding predicates must be folded into the rewritten expression. Now I see it, it's pretty obvious.
Freelance software grandad
software created
extended or repaired
Follow me on Mastodon
Applications, Libraries, Code
Talks & Presentations