[Expat-discuss] Nested calls to XML_Parse

[Dan Rosen]

Hi Derek,

There is an important conceptual distinction here between what you want 
to do and what a parser does. Any parser's role is simply to parse 
serialized data into a programmatic representation of that data, 
regardless of the type of data or its representation. What you're trying 
to do transcends parsing, and falls squarely into the domain of data 
transformation and processing.

In the process of parsing, it is not appropriate (or is, at least, very 
unorthodox) to modify the data stream being parsed. Allowing this 
essentially turns a decidable problem for which there exist efficient 
solutions into an undecidable problem, if you remember your theory. 
Allowing expat to do this would be a very bad thing.

Also, with regard to appending data to the buffer: I don't know what 
expat permits and does not permit in terms of modifying the buffer it is 
currently parsing, within a call stack descending from XML_Parse. Even 
if it does permit this, it seems very sketchy to me to provide access 
from your callbacks to the buffer currently being parsed. Regardless, 
you wouldn't have to make a recursive call to XML_Parse in either case. 
Note also that appending data to the buffer is not what the "isFinal" 
parameter is intended to do. You don't want to think of it as appending, 
you want to think of it as a signal to the parser when you're done 
refilling the buffer from whatever your original data source is (the 
file, for example).

In summary: what you're trying to do is just not what you want to do.

I don't know what exactly you're trying to do with the dynamic content 
you need to generate, but I'd guess that architecturally you'd rather 
approach this in two steps: first parse, then transform. Transformation 
during parsing can be difficult depending on the complexity of the 
transformation (see XSLT), and again, transformation of the source 
document being parsed is simply the wrong thing.

Hope this helps,
dr

Derek Snider wrote:

> It may not "make sense" to embed a call to XML_Parse, but it certainly
> can be useful if you want to have XML elements which generate dynamic
> XML content.
> 
> I went the route of creating a second parser, but XML_Parse should be
> robust enough to properly handle being called by an element handler.  It
> already supports appending data to the buffer (note the isFinal flag),
> why not inserting data at the current point of parsing?
> 
> 
> 
>>-----Original Message-----
>>From: Greg Martin [mailto:Greg.Martin at telus.com] 
>>Sent: June 11, 2003 3:40 PM
>>To: Derek Snider; expat-discuss at libexpat.org
>>Subject: RE: [Expat-discuss] Nested calls to XML_Parse
>>
>>
>>Expat is a stream oriented parser. It seems to me (as a 
>>bystander using the API) that it wouldn't make sense to embed 
>>a call to XML_Parse. You're not starting a new document you 
>>are simply parsing embedded tags and that's what your 
>>callback functions handle. A call to XML_Parse probably 
>>resets the state of the parser or the stream position(and 
>>hence your loop).  I suppose if the contents of a tag was 
>>another xml document you could create a second parser object 
>>and call XML_Parse using that parser ... Regards, Greg.
>>
>>-----Original Message-----
>>From: Derek Snider [mailto:derek at bluegenesis.com]
>>Sent: Wednesday, June 11, 2003 11:42 AM
>>To: expat-discuss at libexpat.org
>>Subject: [Expat-discuss] Nested calls to XML_Parse
>>
>>
>>Why do nested calls to XML_Parse (i.e. calling XML_Parse from 
>>within an element handler) end up putting the parser into an 
>>endless loop?
>>
>>I don't mean code-wise why the library acts this way, but why 
>>is this the intention?
>>
>>Is it not reasonable to want the possibility of XML elements 
>>expanding into more XML to be passed to the parser?
>>
>>It seems to add a lot of unneccessary overhead to require 
>>that nested parsing involve nested creation and freeing of 
>>additional parsers (the only way I could get this to work).
>>
>>Am I missing something?
> 
> 
> 
> _______________________________________________
> Expat-discuss mailing list
> Expat-discuss at libexpat.org
> http://mail.libexpat.org/mailman/listinfo/expat-discuss