[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: No side effects holy cow. ( Re: process order (still...) )
Subject: RE: No side effects holy cow. ( Re: process order (still...) ) From: Khun Yee Fung <KFung@xxxxxxxxxx> Date: Thu, 13 Apr 2000 16:09:36 -0400 |
> Because when I buy my 1024 processor parallel processing machine > I want to pass 1023 sibling nodes to all get processed at the same time > and returned whenever each process finishes, then the remaining > processor slots the returned subtrees into the final result tree in the > correct place, as they come up. So the final tree has the `correct' > order but the actuall processing hapened on each node whenever it > happened. Allowing this is the main reason for not allowing template > processing to have side effects, so disallowing it again in the text of > the rec seems, er, strange. I think this is the only reason behind 'no side effects' holy cow ? I am a hopelessly data-centric person so I am biased on the data side. From my standpoint, being side-effect free is very important for the following reason: The XSLT processor is free to optimize the transformation in an XSLT document as they see fit. I have a very good imagination. I imagine that in the near future the data source is probably an XML database. I also imagine that the result tree will be in the database as well. I can even imagine that an XSLT document is in the database as well. Thus all three trees are in the database. Since XSLT is side-effect free the XML database (with the XSLT processor) can optimize the transformation in an XSLT document any way it sees fit. Parallelization of the processing is one possibility but it is by no means the only optimization possible. As for SQL, good implementations of the XSLT processor will optimize an XSLT document and will make the transformations more efficient. In short, a side-effect free language gives you more freedom to implement the compiler, processor, etc. Now, don't ask me how I would optimize the transformations. I have some strange ideas but they are probably just my imagination. I am sure smart database people will take advantage of the freedom and produce very efficient XML databases for doing XSLT very soon. 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. 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. Regards, Khun Yee XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: That didnt work either! RE: How, John E. Simpson | Thread | Re: No side effects holy cow. ( Re:, Paul Tchistopolskii |
RE: How to get the name of an eleme, Selva, Francis | Date | RE: That didnt work either! RE: How, Selva, Francis |
Month |