NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Cool, thanks! (Score:1)
Will take a look at that toolkit when next I dive in to EventPath implementation (see XML::Filter::Dispatcher [cpan.org] for that, those of you interested in streaming XPath implementations).
Thanks for the pointer.
- Barrie
Re:Cool, thanks! (Score:2)
Somehow I thought you would read this :) As for XPath-on-streams freaks, well, if it doesn't have to include implementer then you can count me in. You can also count the guy working next door from me that wants to do that kind of thing for our Publisher software. Then you have the STX guys as well. And prolly a number of other people, lo! we're a crowd, lets take over the world!
It sure would be nice having an optimized matcher in XFD, especially one that can handle all of XPath on a stream.
-- Robin Berjon [berjon.com]
Reply to This
Parent
Re: STX (Score:1)
EventPath is a superset of XPath which buffers events as necessary for in-order delivery in the event of possibly out-of-order matching expressions like /a[b]/c. And it gets most things correct :). This Xaos stuff might be a better way of implementing it, however; X::
Re: STX (Score:2)
Oh, I remember STX as a subset of XPath, haven't looked that way in ages. Xaos immediately reminded me of XSD as what it does to match seems quite similar, notably related to what they call Total Matching (I think you do something quite similar, but I haven't thought that through yet). You could probably go indeed faster with a state machine, and I've been wondering if it's possible to see a stream as a b-tree as explained in Murata's [coverpages.org] (can't find the PPT, it contained graphics that made it a lot clearer)
-- Robin Berjon [berjon.com]