general purpose tranformation language (Re: No side effects
From: Khun Yee Fung > >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. Being consistent with XML-ish way requires turning /element[@attr="5"] into: <expr> <path absolute="yes"> <step>element</step> <predicates> <equality_expr> <attr>attr</attr> <value>5</value> </equality_expr> </predicates> </path> </expr> ( Actualy, it will be even more complex ). Because current XSLT document is a *mess* of: XSLT constructions written in XML-ish notation and XPath expressions written *not* in XML-ish notation That means *some* transformations of the XML-ish part of XSLT document are possible with XSLT, but any transformation of XPath 'parts' of XSLT document is *not* possible. Also, I don't understand why people are now happy with those well-known LISP ( and assembly ) abilities to threat code as if its is data? Self-producing and self-modifying viruses are of course fun to write, but with no doubt this marginal technologies are rarely used and ususaly are absolutely not supportable on a long run. Conclusion: any 'advantage' of having XSLT XML-ish is plain mythical. 1. "Saving parser footprint" is mythical, because there is XPath part which anyway requires custom parser. 2. "Verbosity is good" is mythical, because there is XPath part which is not verbose. 3. "Ability to process XSLT documents with XSLT itself" is no doubt mythical, because common practice of software development says that the amount of self-modifying code should be minimized, if the task is to build something supporttable. Let me make (3) clear. Let's imagine that you are *constantly* using some Java program (A) to *modify* the source code of some other Java program (B). I think that even in this crazy world there will be not a big number of people who will install *such* a (B) thing into production environment ( the exception could be some AI / expert system, but there is no need in Java ( or XSLT ) - LISP and Prolog are doing well ). To make it absolutely clear. I'm not saying that there is something bad with *generation* of Java code out of some *data*. Nothing is bad with generation of XSLT stylesheets out of some *data*. But XSLT stylesheet is *not* the *data*. It is *code* do we like it or not. That means when somebody is saying that "I'm producing XSLT stylesheet out of some other XSLT stylesheet, and I feel happy ( or I'm producing my Java code out of some other Java code )" the only thing I can say is: "You are good hacker. You are good in writing viruses. So what?" In any environment that I know, people are constantly trying to *separate* data out of processing ( code ), to allow 'not experienced' users to get concentrated on supplying data. "It is good to produce code out of code" - is just a marginal slogan. I was used to write plenty of self-generating / modifying code in assembly and Mit-Logo. This is *very* marginal occupation and always results in bad programs. ( BTW - the only reason for those hacks in assembly is efficiency.). I think that I can *always* find the non-self-modifying invariant of any XSLT stylesheet, replacing the 'source' XSLT stylesheet with some 'XML-descriptor' - and my invariant will have all the 'advantages' of 'self-modifying' approach but also will be supportable. That means there is actualy no need in *self-modifications* of XSLT stylesheets - but there is some need of generation of XSLT stylesheets from XML source ( data ). That means there is *no* need for XSLT to be XML-ish itself. Uh. XML-ish notation of XSLT makes sense *only* in HTML-templatish mode ( without apply-templates e t.c. ) But this opens another set of questions, because in this part we have only 50% of XSLT accessible. XSLT is nice thing. Nice idea. Some concepts are interesting. But no doubt it is not the end of the story. Monsters can not live, and XSLT smells like a monster with all the hacks it has. I understand that it is not fair to say that, because the idea was to have *both* parts ( XSLT and XSL ) inside one product e t.c. e t.c. Political games affected XSLT a lot. I'm not blaming XSLT WG ( because I think they did the best in the situation they had ) - I'm just explaining that some XSLT claims are mythical. And I also think that if W3C will be honest and say loudly that "XSLT is not a general-purpose transformation language for XML. Currently we have no standard for general-purpose transformation language for XML, but our plans are ..." This could help. But I don't expect this to happen. > 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. SELECT xpath, xpath, xpath FROM xpath, xpath WHERE xpath, xpath Very natural to some of us. > >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. YES!!!! ;-) It was not designed for XML repositories. It was not designed for rendering financial reports ;-) It is not general-purpose XML transformation language. But that also means it should not *pretend* to be general-purpose XML transformation language. > 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.). XSLT is good for some kind of documents and is bad for some kind of documents. General purpose transformation language for XML has to be invented. I'l be very glad to get access to your work in this direction and I know for sure that there if many of us, who are looking into that direction ( BTW - with no surprise - most of 'us' are experienced software developers who *do* know XSLT pretty well and have been *very* excited about XSLT at the beginning. I think there is some pattern here ;-) Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format