Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Co-operating with Architectural Forms
 > > The common problem that arises here is that someone has a 500MB XML > > catalog and their machine bombs when they try to transform the whole > > thing at once. So they write a SAX reader that grabs each "author" > > element and transforms it individually using a cached XSLT stylesheet. > > This is in effect what Saxon's saxon:preview extension does for you. Yeah, that beats asking the user to write their own SAX filter, but still requires some level of collusion with the stylesheet developer. > limited, though it might become rather more feasible if the optimizer has > knowledge of the schema. It only takes a single template that uses "..", Definitely schema is an area where the optimizations could be discovered more accurately. > make the optimization invalid, unless you know for certain that these are > only selecting within the current subtree. Exactly, this is the point of "forward-only XPath". In essence, you are figuring out which XPaths in which contexts are going to be "only selecting within the current subtree." And of course the "chunking" is artificial, so another way to look at it is "what is the smallest chunk size that allows all relevant XPaths to take place within the context of that chunk?" It's not an *easy* problem to solve, and in many cases the answer will be "the whole document". But this is just my guess as to why the original poster was relating forward-only XPath and XSLT. > > Mike Kay 
|
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
|
|||||||||
