Re: [xsl] Merging 2 XML's in to 1 output XML (Performance Issue)

[Elliotte Harold <elharo@xxxxxxxxxxxxxxx>]

Michael Kay wrote:

> That's not a bug then, it's a design decision, or more particularly a
> question of interpretation of the SAX specification. Does the ContentHandler
> specification imply a contract that the sequence of events you pass to it is
> well-formed? There's no right answer; but there are ContentHandlers out
> there that make that assumption and that fall over in a messy heap if you
> pass them two top-level element nodes.

My ContentHandler is ready to handle that. More to the point, any 
ContentHandler that expects to receive data from an XSL transformation 
had better be ready to handle that without falling over and dying, 
because as we all know XSL transformations don't always generate 
singly-rooted trees.

I don' t think it's unreasonable to expect that one can use the 
published API to receive the results of an XSL transformation without 
losing any pieces.

Moving beyond XSLT, I think any generic ContentHandler had better be 
ready to handle a lot worse things than a multiply rooted tree. While 
driving a ContentHandler through a real XML parser may produce a nicely 
well-formed event sequence, once SAX filters are applied anything can 
and does happen. End-tags can be missing. Elements can overlap. Element 
names can contain spaces. Binary data can appear. Almost anything can 
happen. A ContentHandler that does not control its parser should be 
ready for this.

--
o;?Elliotte Rusty Harold  elharo@xxxxxxxxxxxxxxx
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim