Re: No side effects holy cow. ( Re: process order (still...) )

[Paul Tchistopolskii <paul@xxxxxxx>]

> 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