This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
general purpose tranformation language (Re: No side effects holy cow. )
- To: xsl-list at mulberrytech dot com
- Subject: general purpose tranformation language (Re: No side effects holy cow. )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Mon, 24 Apr 2000 21:25:57 -0700
- Organization: The Qub Group
- References: <E09B8717558DD211BF0300609793FBB0020160EA@MAILSERVER>
- Reply-To: xsl-list at mulberrytech dot com
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