OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] More on taming SAX (was Re: [xml-dev] ANN: Amara XML Toolk

[ Lists Home | Date Index | Thread Index ]

* Uche Ogbuji <uche.ogbuji@fourthought.com> [2004-12-26 13:12]:
> Alan Gutierrez wrote:
> >* Jeff Rafter <lists@jeffrafter.com> [2004-12-23 13:43]:
> > 
> >
> >>>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.
> >>   
> >>
> >
> >   I have a SAX library (in Java) that keeps the stack around, but
> >   not the preceeding siblings. It is quite useful.
> >
> >   It is, actually, very useful to keep a stack around that has a
> >   hash table for each level of the stack, it allows for the
> >   devleopment of strategies that are themselves stateless.
> >
> >   Adding the implied stack goes a long way to make SAX event
> >   processing a more practical solution for a lot of problems.
> > 
> >
> Yes.  This is a useful technique I covered for Python in my article 
> "Location, Location, Location 
> <http://www.xml.com/pub/a/2004/11/24/py-xml.html>":

> http://www.xml.com/pub/a/2004/11/24/py-xml.html

> I think that while useful this technique can still leave a lot of state 
> wrangling to the programmer, which is why Amara has several modules that 
> go further.

    Yes. A lot is still left to the programmer with my tool set, but
    it does pick up a lot common SAX tasks.
    I've wondered about what more I could do.

    Hmm.. Read the article. I was talking about how I keep a stack
    of the elements around, and how a silly thing I did turns out to
    be very useful. In the stack of events, for each event, I keep a
    java.util.Map and tuck all sorts of things in there.

    Twice now I've create a little langauge in XML and used SAX to
    parse it. Once I understood what I could and could not do, it
    got pretty easy to express a chore as an XML event stream. It
    was easy to keep track of the chore by tucking state into the
    java.util.Map. Kinda Perlish, but that's me.

    I was wondering if I couldn't specify some of those invidual
    chores within an XML Schema document. When a certian object is
    found in the event stream, acording to XML Schema, Java source
    could be executed, perhaps as a generated class with member
    variables mapped to attributes or the values of childen.

    I've thought about using an XPath tracker in error reporting to
    my library, which would be very simple to add at this point, and
    it's necessary, I think because the document locator loses
    meaning when I chain together a bunch of SAX filters.

    In any case, I'm reading through some of the other articles
    you've been posting. This is a very interesting discussion.


Alan Gutierrez - alan@engrm.com


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS