commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: Digester and attribute matching?
Date Tue, 13 Apr 2004 08:49:20 GMT

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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message