Emanuele D'Arrigo wrote:
I think it'd be good to implement some kind of reverse xpath evaluation, where the algorithm start from the last component of the xpath expression and works its way backward, from the element to be verified toward the root. I.e. given the tree:
<alpha> <bravo /> <charlie> <delta /> </charlie> </alpha>
and given the element <delta> and the xpath "/alpha/bravo/*/delta", the algorithm would first verify that the element's tag is "delta". Then it would check that <delta> has a parent, any parent. Then it would check that this parent is the child of "bravo", but as that's not the case the evaluation would return False: the element is not matched by the given xpath expression. I guess things might get tricky evaluating in reverse more complex cases and functions...
"might get tricky" is clearly the wrong wording here.
Why don't you apply the XSLT to the subtree *before* you insert it? Because some transformations only apply "in context". I.e. suppose a transformation only applies to a <div> element if it is a child of the <body> element. I must first attach it to the <body> element and only then I can transform it. No? Ok, then why don't you apply it to the element *after* inserting it?
IF the transformation is specific to the subtree sure, as the rest of the document would be unaffected. But the general case is that the transformation in question might be part of a bigger xslt file which might have been applied already to the rest of the document. Applying the same xslt file again to the whole document might have undesirable consequences.
Note how I wrote "element", not "document". Stefan