Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

XPath Optimisations 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Cool, thanks! (Score:1)

    by barries (2159) on 2003.01.29 10:52 (#16491)
    Not sure of any other XPath-on-streams freaks, let me know of any.

    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

    • 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]

      • STX isn't XPath; it's a matching language and designed for streaming environments. I've seen mentions of constructs that allow you to collect read-only source trees, but the matching is limited to what's handy without any buffering at all.

        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::

        • 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]

    • Hand raised, waving frantically

      It has been in my todo list for ever... maybe between ripping the XPAth grammar from XML::Filter::Dispatcher and this I can write something really cool for XML::Twig.

      I'd bet on you getting there first though ;--(

      --
      mirod

      • Couldn't you go at it the lazy way and build that Twig functionality layered over XFD?

        --

        -- Robin Berjon [berjon.com]

        • Here's how X::F::D does its pale immitation of TWIG-like things:

             '/*/b' => [ 'hash()'   => sub { use BFD; d xvalue } ],
             '/*/c' => [ 'struct()' => sub { use BFD; d xvalue } ],

          Those two will print out hashes (returned by xvalue()) for each <b> and <c> in the root element. Mind you, this isn't meant to look pretty or replace XML::TWIG, it's meant to provide limited TWIG-like functionality in the X::F::D environment so you can conveniently slurp a tw

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.