Daniel Veillard <[EMAIL PROTECTED]>: > [snip] > > Well if I wrote pattern.c for libxslt and later migrated this to > libxml2 it's really because they work differently and their cost/benefit > are really different. Except taking a precompiled form of xpath.c > expressions and trying to interpret it in a different way. Currently > there is no code which seems to satify your needs, statement which > itself is hard to assert as you didn't specify them.
Yes, I know -- I'm not 100% certain about what I need myself, yet. I do think I need basic location paths and some form of negation (e.g., "nodes that are not code nodes"), which I guess is most easily done using e.g., 'node()[not(self::code)]'. > And pattern.[ch] in libxml2 is a work in progress which may or may > not suit your needs in a distant future, but again since you didn't > specify what you want... Right... :) As I suspect my needs for efficiency might not be all too extreme, I have -- for now -- simply used xmlXPathEvalExpression(...) along with one loop traversing the ancestor chain and one looking through the returned node-set (if any). Sort of a "brute force"-application of XPath matching to get the XSLT pattern semantics (or something similar), but it seems to work, so... (Of course, this doesn't enforce the restricted subset of XPath, but that may not be too critical.) -- Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake] _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
