[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: More on taming SAX (was Re: ANN: Amara XMLToolki

• To: Uche Ogbuji <uche.ogbuji@f...>
• Subject: Re: More on taming SAX (was Re: ANN: Amara XMLToolkit 0.9.0)
• From: Jeff Rafter <lists@j...>
• Date: Thu, 23 Dec 2004 10:43:29 -0800
• Cc: xml-dev@l...
• In-reply-to: <1103792754.4600.81.camel@borgia>
• References: <1103757598.10272.67.camel@borgia> <20041223055359.GK25900@s...> <1103791522.4600.68.camel@borgia> <1103792754.4600.81.camel@borgia>
• Reply-to: lists@j...
• User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> While on the topic of SAX taming features in Amara, there is also
> amara.saxtools.xpattern_sax_state_machine, which I didn't even bother
> mentioning in the announcement (too much to cram in).

Can you expand on your expansion? As I was reading this I was thinking 
that in the Java/C# world an interesting approach would be to keep a 
pseudo DOM stack for the event hierarchy. Maybe something where you keep 
everything at an ancestral level intact while parsing


<foo>
   <bar1>
     <baz1/>
     <baz2/>
   </bar1>
   <bar2>
     <baz1>
       <sub/>
     </baz1>
     <baz2>text</baz2>
   </bar2>
</foo>

So when the event stream reached /foo/bar2/baz2/text() you would have 
the following in a DOM like structure:

   foo
     \
      bar1 (... no children)
      bar2
        \
         baz1 (... no children, just the previous sibling and attrs)
         baz2 (only the StartTag)

I am not sure that the preceding siblings would be very useful and have 
more chances for pathological cases but when I construct mini-trees this 
is the subset I find handy. It is useful when working with an editor to
understand the immediate context. Unfortunately by requiring the 
previous siblings you have to maintain quite a bit more... the whole 
preceding branch of the tree.

> This module takes an XPattern (e.g. "/xbel/folder/bookmark") and
> generates a state machine which can be plugged into any regular SAX
> handler.  In this way, you can automatically look for certain XPatterns
> which have interesting bits of code for you to process, and ignore the
> rest.  This is sort of the opposite of Tenorsax: embrace the state
> machine, but automate it, rather than sweeping it unto a fancy
> framework.

Karl Waclawek has done some work in this area in both Delphi and C# in 
his toolkit XPEA. But I am sure he will take some ideas from this thread 
as well... it is all very interesting.


Cheers,
Jeff Rafter

• Follow-Ups:
  • Re: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0)
    • From: Alan Gutierrez <alan-xml-dev@e...>
  • Re: More on taming SAX (was Re: ANN: Amara XMLToolkit 0.9.0)
    • From: Uche Ogbuji <uche.ogbuji@f...>
  • RE: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0)
    • From: "Michael Kay" <mike@s...>
  • Re: More on taming SAX (was Re: ANN: Amara XMLToolkit 0.9.0)
    • From: Karl Waclawek <karl@w...>

• References:
  • ANN: Amara XML Toolkit 0.9.0
    • From: Uche Ogbuji <uche.ogbuji@f...>
  • Re: ANN: Amara XML Toolkit 0.9.0
    • From: Uche Ogbuji <uche.ogbuji@f...>
  • More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0)
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: RE: XPath and XPattern (was Re: More on taming SAX)
• Next by Date: Re: More on taming SAX (was Re: ANN: Amara XMLToolkit 0.9.0)
• Previous by thread: Re: XPath and XPattern (was Re: More on tamingSAX)
• Next by thread: Re: More on taming SAX (was Re: ANN: Amara XMLToolkit 0.9.0)
• Index(es):
  • Date
  • Thread