From: Bob Hutchison <hutch@...>
Date: 2001-11-14T12:08:49+09:00
Subject: [ruby-talk:25144] Re: XML support in the standard lib; what  	exactly?


Sorry, somehow I missed this earlier.

On 01/11/13 4:52 PM, "Bob Gustafson" <bobgus@mcs.com> wrote:

> On 14 Nov 2001 06:13:27 +0900 Bob Hutchison <hutch@xampl.com> wrote:
>> On 01/11/13 1:41 PM, "Bob Gustafson" <bobgus@mcs.com> wrote:
>>> 
>>> ----------------------------------
>>> 
>>> Striking out on a slightly different direction, maybe some discussion of
>>> the 'requirements' of a ruby xml processor would be in order.
>>> 
>>> Requirements - i.e., what do you want to do with the XML documents?
>> 
>> 0) parse an XML document and generate SAX-like events without having to have
>> the whole document in memory. (I'm getting boring :-)
>> 
> ... snip
> 
> Are you interested in having events for 'every' tag in the document, or
> only a (small) subset?

Like SAX... Element start, element end, content, comment, processing
instructions etc.

> 
> Something like:
> 
> 1   par = XMLsnip.new(doc_pointer)
> 2   sn = par.snip('form')
> 3   sn = par.snip('table')
> 4   xn = par.snip('a')
> 5   po = sn.snip('td')
> 6   po = sn.snip('td')
> 
> Where each of the snipped pieces are the contents of the next instance of
> that tag in the snip object?  The whole document does not have to be in
> memory as each 'snip object' contains a pointer to the next character in
> the snip object. This pointer is incremented as more (sub) objects are
> found in the object.
> 
> Thus the objects 'po' in lines 5 and 6 point to different (successive)
> points in the snip object 'sn', which in turn points to the beginning of a
> <table> which is after a <form> in the original document.
> 
> Each snip operation on an object increments the pointer within that object.
> Thus the snip object xn defined in line 4 points to the beginning of the
> <a> element after the <table> element after the <form> element in the
> original document.
> 
> This is a pretty dumb way to extract data from XML (actually HTML in my
> case) web documents, but it works for me in this (limited) usage.
> 
> 'Works' means that the parser thinking is easily reusable without having to
> rewrite (re-think) the parser guts.  It was quicker to do this than wrap my
> head around SAX, etc.

If I understand what you are getting at then the whole document has to be in
memory and parsed. This won't work for me. I need an event based parser like
SAX (to be more precise, I need a parser with a bounded memory requirement
(like SAX)).

Actually, to really screw everyone up (sorry), what I need is SAX, what I
*want* is a pull parser (for example:
http://www.extreme.indiana.edu/soap/xpp/ though without the SOAP
pre-occupation) -- but I can easily make a pull parser from a SAX-like event
stream. I'm using XPP in the java version of this project and it is quite
nice. However, XPP is *really* SOAP focused so it doesn't report comments,
processing instructions, or any of the parsed entities defined in a DTD --
it won't provide the whole infoset.

Cheers,
Bob

> 
> BobG
>