On 12 Apr 2004, at 23:09, Simon Kitching wrote:
On Mon, 2004-04-12 at 06:09, robert burrell donkin wrote:i've had a longer think about this, and i'm not really sure anymore
that there's any XPath engines that this would work for. the other
issue is that some XPath expressions really require the whole of the
document to work with. (but scott would probably know better than me if
this is feasible so if he's lurking, i'd be interested to hear his
opinions.)
I'm sure you're right about xpath requiring the whole doc in memory, which certainly can't be done in Digester1.0. Personally, I'm fond of the "light" sax-based approach.
+1
in terms of adding support for attribute matching, i'm a little reluctant to consider modifying the matching string syntax but i suppose that we could add a wrapper rule (even though it's not a very elegant solution).
the current design for Rules makes it easy to create new rules implementations but is limited by the amount of information available to the implementation. the string syntax passed into the call is the limiting factor.
Yep. I have been thinking about some generic "conditional-support"
though. Perhaps we could say that any text within [] brackets in a
pattern is a condition. This doesn't affect which rules are selected,
but the condition part is then somehow evaluated as a filter on those
rules (maybe just passed literally to the rule so the rule can interpret
it and decide whether to fire or not?). This would be moderately
xpath-like. But I still think this is more a candidate for 2.0 than the
1.x series.
i have think that adding support for conditions to the digester engine would introduce unnecessary limits for future flexibilty but i suspect that any solution which does not expose the entire SAX stream to the matching engine will also create severe limitations (both in terms of performance and for future growth).
maybe digester 2 should be a container supporting multiple matching engines each being fed the full SAX feed. maybe each engine should act as a container for Rule implementations. (though some prefer the word Action).
this has set me wondering whether something like XSLT would be a cool
to map XML to objects. rather than templates, rules would be applied to
the products of XPath expressions. xml rules could probably be mined
but still would be a lot of work.
I've been thinking about xpath-like pattern support too. I've got a "to-do" list for 2.0 (if there ever is one) and that is on it.
Rather than XPath/XSLT, though, I would look first at STX, which is the sax-based equivalent of xslt (which as you note is really DOM-based). I haven't looked in-depth at this, but it seems "copacetic".
copacetic? (googled and the average meaning seem to be 'cool, fine'.)
but you're right that supporting STX (or rather STXPath) seems like a much better plan than supporting XPath.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
