Re: Visiting your cake and eating it too (was Stupid Questio
From: "Sean McGrath" <sean.mcgrath@p...> > I''ve learned from bitter experience that doing XML processing monolithically > for efficiency reasons is almost always a bad idea. Processes that are needless coupled are monolithic. The visitor pattern uncouples the visiting from the processing; it creates an interleaved layer rather than relying on separate processes in series. > I find again and again that if you design and implement > loosely coupled XML systems - ignoring efficiency concerns - efficiency has > a way of sorting itself out without adversely impacting the design. Efficiency comes from choosing the right algorithm above all. For my concern, which is desktop XML systems, efficiency is very important. Not all XML systems are loosely-coupled remote processes. A person with one computer with one CPU clicks "validate" and wants an answer as soon as possible; indeed, they want to have it already checked in the background or continuously updated. > Any schema language, query language or any other XML technology that > justifies the complexity that is concomitant with monolithic design on > efficiency grounds should be treated skeptically. It is just for each document d for-each node n in d for-each registered-method r of n do n.r() rather than (worst case) for each method m for document d for each node n in d if n.m exists, do n.m() You well be right that parallel and p2p processing can has excellent performance. But these can only be aided by specs which can be efficiently implemented for streams, DOMs and grids of spawning functions. Integrated and modular schema languages does not mean monolithic. Cheers Rick Jelliffe
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