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

-----Original Message-----
From: Paul Tchistopolskii [mailto:paul@xxxxxxx]

>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).

I don't mind verbosity. I like consistency. So I don't mind that XSLT
documents are XML documents. I want to be able to transform XSLT documents
as well. Meta XSLT templates are useful to provide additional flexibility. I
hope I could do the same with XPath. Not that I have an example why I need
that. 

I guess I don't have a strong conviction either way. I will use whatever is
available for me.

> PS. I'm happy with XPath in it's current form.

As a path notation, it is as good as it goes, I guess.

I am just looking for a tree pattern matching notation. A notation that
allows you to match nodes and subtrees, not just paths in the tree. Granted
I can specify all tree patterns in XPath, I just want a more natural way.

>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 guess we should not expect XSLT to be good for something it was not
designed for.

>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.  

I have an example using XSLT to generate a PDF file. It was a good exercise
for me. But perhaps generating TeX documents is more reasonable (Of course
it has been done, somebody on this mailing list can tell you that.).

Regards,
Khun Yee


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list