general purpose tranformation language (Re: No side effects holy cow. )

[Paul Tchistopolskii <paul@xxxxxxx>]

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