Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Merging 2 XML's in to 1 output XML (Performance I
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
