Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 11:08 AM 8/4/2008, Andrew wrote:
> I submit that speculating on performance differences vs alternatives is > somewhat pointless, since it will depend on the implementation. It's not > that it couldn't be optimized (especially if it were supported in the > parser), so much as that it might not be. Indeed there isn't. :-) Which is not to say that the battle-scarred veteran can't say "oh you know, that's likely to be expensive, and we've learned to work around potential problems with it in advance", etc. I think we should be moderate in everything, which includes allowing for a certain amount of excess. Just to recap: -- or you write a SAX filter that annotates the input tree and makes it really really fast ... elegance being in the eye of the beholder ... - there is xml:lang and the lang() function, which were invented for this particular task, but many implementations (including Saxon) will just walk the ancestor axis behind the scenes, so you don't benefit from switching to xml:lang from a proprietary solution -- as far as performance goes, while allowing that there may or may not be other costs and benefits related to using a standard mechanism in your particular situation ... This really isn't about premature optimisation... Fair enough. Cheers, Wendell ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
|
