Subject: Re: No side effects holy cow. ( Re: process order (still...) ) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Thu, 13 Apr 2000 19:07:36 -0700 |
> 2. If document is large - it'l eat the entire memory ( XSLT lacks > streaming), > so the problem will be not to find extra processors, but to find > some more > memory. > > But if all three (or more documents if you use document()) trees are in an > XML database, you would not have that problem. I image that by parsing an > XSLT document, it is compiled into something that can be optimized by the > database. After that, the tradeoff between memory and processor power is > something that you have to find a good balance on. This problem domain is targeted by some other W3C recommendations ( XQL and XML-QL for example). I perfectly understand all the reasons why so many of us are trying to turn XSLT into 'something better', but I simply know that occasional shifts of problem domains without redesigning the entire thing usualy result in bad software. Any exceptions ? > By the way - another XSLT holy cow is xmlish notation. > "To save parser footprint". Anyway XSLT implementation has > to implement XPath parser, so savings are mythincal, but > extra-verbosity problems are real. > > I guess the proliferation of all the XML vocabularies shows that there was a > pent-up demand on a simple and universal format to specify structured data. > It was like ASN.1/BER for the telecommunication people. And XML is even > better than ASN.1/BER. > > I always find it a bit ironic that it is difficult to process XPath > expressions in XSLT. But then processing C++ programs in C++ is not easy > too. I am just spoiled by the power of the XML notation. I don't understand. If you are saying XML-ish notation is appropriate thing here, that means XPath should be XML-ish as well ( for the reasons why the rest of XSLT have been made XML-ish). Either 'verbosity is good' or 'verbosity is evil'. Why <xsl:call-template . bla-bla -bla 10 lines to create a string of N spaces ( with incredible preformace overhead ) but at the same time {/some/element[@attribute]} ? Is XML-ish verbosity good or bad ? OK, OK. Let's call XPath 'shorthand' - this should close the topic. Rgds.Paul. PS. I'm happy with XPath in it's current form. PPS. I'm absolutely happy with XSLT in HTML-templatish mode. Very consistent, reasonable and nice thing. I mean XSLT in HTML-templatish mode. XML-ish form is perfectly reasonable here and no <xsl:call-template's allowed ;-) . PPPS. Of course it could be also used for some transformations/conversions. If you can afford that simple convertor will always eat all of your memory always loading the entire document, even all you wanted was just to caculate a number of 'titles' in the document. XSLT could be also used for many-many other things. But attempts to use it for those 'many-many' things usualy show that XSLT is not as good for those problem domains as it is for it's original problem domain. I could start providing a long explanations and examples of particular problems I encountered before I got to this point, but I think anyone who tried to utilize XSLT for rendering, for example, financial reports into plain text - already knows what I know. Thanks to Michael Kay - the only hacker who cares about real life, not waiting for the time when every CPU on the planet will have gigs of RAM. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: No side effects holy cow. ( Re:, Khun Yee Fung | Thread | RE: No side effects holy cow. ( Re:, Khun Yee Fung |
Type of an <xsl:param>, Jeff Lansing | Date | Re: No side effects holy cow. ( Re:, Paul Tchistopolskii |
Month |