[4suite] meta xslt

[Paul Tchistopolskii]

----- Original Message ----- 
From: MJ Ray <markj at luminas.co.uk>

> > Could we have a particular example of 'simple task like this' ?
> 
> The case in question is a good example: using XSLT to reformat some
> XML that just happens to be XSLT itself.  Remodelling XML is what XSLT
> is designed for, after all.  

No, it was not.

Before making claims like this, I think you should read the beginning 
of XSLT Recommentadion ( by W3C ) which explicitely says what was 
XSLT designed for.

Or you can read 'What is XSLT' article on http://www.xmlsuck.com
( which also has some links to particular places of Michael's book )

Or you should re-define 'remodelling' then.

> There are probably other ways to do it
> (as always), but it seems wasteful to ignore the purpose-built tool
> for it.

... sure ... by the way, who told you that XSLT is this 
"purpose-built tool"  ? 

*Not* me and *not* W3C and *not* creators of XSLT indeed.

> > Let us stay on topic, please and discuss the real stuff, if possible.
> 
> I'm trying to.

If this means that  you're talkign about pretty-printing of XSLT 
stylesheets - you're right. Attached please find the snippet which does it.
No need in namespace aliasing by the way.

> > You're saying that your way is "standard" and my way is "non-standard" ?
> 
> The original request was staying within the XSLT standard and your
> suggestions went outside it.  

I've provided  2 ways of refactoring XSLT code to avoid XSLT-modifies-XSLT

1. The first one is 100% XSLT standard.  ( even XSLT 1.0 - use document()  )

2. The second one is at the moment outside of XSLT, but is supoported 
not only by saxon and 4xt, but also this typical functionality and style of 
programming is supported by any existing language which implements 
'eval' . All of functional languages *do* implement 'eval' I think. Please 
point me to the language, which does not ?

Some craziness happens to be a part of XSLT spec? Big deal. 
There was plenty of them in XSLT 1.0, like 100% fake but 
'standard' Result-Tree-Frangment entity. 

Just wait for XSLT 2.0 and your claim that *all* of solutions 
I'm talking about are 'not standard' will disappear. 

I remember people saying that 'xt:node-set' is not standard 
with the straigth face and explaning that "because it is not 
standard  you should *not* use some related technologies" 

Now the same people have no argumentation against pipes 
and I'm learning that 

'chained transfromations is a *standard* mechanizm in XSLT
by original design'

This is also not true. 

> Surely that is obvious?  It's not *my*
> way -- why are you making this so personal?  Does people not
> understanding your reasoning upset you?  Sheesh, sorry...

Nothing can upset me after the school  I've  got in XSL-list, where 
some strange guys  were explaining to me what is 'localhost', making 
assumptions that I should be a plain idiot, because I say something bad 
about those 'Result-Tree-Fragments'  and other pieces of wisdom, 
blessed by W3C gods. Every time I'm talking about some real 
XSLT problems ( and the lack of String -> Xpath typecast 
*is* such a problem ) - some person appears and says that :
"It is because you don't get functional programming". Then 
after I'm motioning mit-logo it sometimes helps. If mit-logo
does not help, I'm motioning Hasckell and *then* by some magic, 
those 'I'm functional programmer' people start listening to what 
I'm saying. 

How can I be upset ? I could be upset if I'd find somebody 
who will argue with me *not* talking about "oh, you don't know 
functional programming". 

The things I'm talking about have *nothing* to do with 
'functional programming' and starting holy war ( that was *not* 
me who've started it ) is not the way to keeps things on topic.

I'm writing production and *darn complex* XSLT code for a long time
( because I have XSLScript for this. Nobody can write XSLT 
transformations as complex as I can *not* because I'm smart, 
but because I'm using a C where the rest of the world is writing 
in PDP assembly. I assume that  everybody knows that originally
C was just a macroprocessor for PDP instruction set ? )

With my experience of writing complex and scalable code, I know that 
if you want a scalable and supportable solution you should not be 
building on "xslt-generates-xslt".  You're saying that "no, XSLT 
was designed for XML remodeling". That is simply not true. Period.

How can I be upset when I know that you are wrong in almost every 
argument you're making ? I'm just sad that all the XSLT developers 
( including me ) are going through the same cycles again and again. 

XSLT is hard -> 
XSLT is good -> 
XSLT is not for general purpose transformations 

I'm sorry, today I have to go to some other state of the US 
for next 5 days. To bugfix yet another shitty system. I'll 
not be reading this list for next 5 days, and if you want
me to answer something, could you please 
crosspost it to paul at qub.com ?

However, I don't think there is anything to discuss, because you 
haven't said anything new to me. I suggest browsing archives of 
xmlbastard.com and www.xmlsuck.com

Visiting www.jclarck.com and reading the slides he has made may 
also be helpfull.


Rgds.Paul.

XSLT *pretty-printing* XSLT

In XSLScript notation.

X:stylesheet {

X:output method="xml"
X:param indent-increment="'   '";

X:template noname(indent="'&#xA;'") = "*" {
 !{$indent}

 X:if "name()='xsl:template'" {
  !{$indent}
 }

 X:copy {
    X:copy-of "@*"
         !!( indent = "concat($indent, $indent-increment)" );
    X:if "./* " { !{$indent}  }
 }
}

 
X:template = "comment()|processing-instruction()" {
    X:copy;
}

X:template ="text()[normalize-space(.)='']" {}

}