[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

	> 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

---