This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: No side effects holy cow. ( Re: process order (still...) )
- To: xsl-list at mulberrytech dot com
- Subject: Re: No side effects holy cow. ( Re: process order (still...) )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Thu, 13 Apr 2000 19:07:36 -0700
- Organization: The Qub Group
- References: <E09B8717558DD211BF0300609793FBB0020160AB@MAILSERVER>
- Reply-To: xsl-list at mulberrytech dot com
> 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