This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT V 1.1



----- Original Message ----- 
From: Jeni Tennison <mail@jenitennison.com>

> This solution wouldn't handle situations where there are multiple documents
> being accessed through the same document() call:
> 
> <class-files>
>   <file href="class1.xml" />
>   <file href="class2.xml" />
>   <file href="class3.xml" />
> </class-files>
> 
> <xsl:for-each select="document(class-files/file/@href)/classes/class">
>   <xsl:sort select="@name" />
>   ...
> </xsl:for-each>

What is this?  This should not work in current XSLT.

Could you please write some accurate usecase?  And 
then I'l try to show how to do it without document() 'magic' .

I guess this is about third 'head' of current document() 
( on-the-fly aggregation, masquesrading lack of RTF->node-set 
conversion. ) ?

> If document() accepted only single strings (or nodes), sorting a collection
> of classes drawn from several files would, I think (?), only be possible by
> going through an intermediary result tree fragment.

And what's wrong with usage of intermediate variable ? 
With current XSLT engines both Input  and Result are *anyway* 
in the memory, do you use intermediate variable or not. 

If good old xsl:for-each is so 'bad' for aggregation that it should 
live *inside* document()  why not place xsl:sort into document() ? 
Just kidding. I want to take for-each *out* of document(). Not 
to place *more* 'handy things' into document(). 

Rgds.Paul.

<background severity="skip">

PS. I think those who like situations "just one magic word 
which does several slicing and dicing things" - they should 
like perl and be 'good perl hackers'.

I think nobody in the entire world knows 'everything' about 
every perl construction. It is what perl hackers call 'fun'. Constant 
learning of new constructions and writing one-liners which 
are readable only by person who wrote the one-liner. 

Because my job for years is to fix huge heaps of 
garbage written not by me, but by perl / C++ e t.c. 
'hackers'  ( I don't know  why do they usually quit after 
writing the 'core' . I think because making it all *really* work 
is no 'fun' ).  I have  a bit strange point of view on software 
development.

I want code to be terse, but traceable. It is usually not 
a problem *at all* to 'write' anything. The problem is to make 
it work - and this usually means  tracing the application's 
dataflow, re-engineering code written not by me. 90% of my 
day job and day job of *millions* other developers is tracing 
the internal dataflows in the code  usually written *not* by 
them. *This* activity eats the time of professional developers. 
( Sure - scientists don't spend their time on this crap ). I'm 
not a scientist. I'm yet another janitor who makes it  all *really* 
work. That's why I'm now very excited about 'access by value' 
and pipes. It allows tracing dataflows, because it makes 
hard to produce *not* traceable dataflow. 

How short is the code for some exotic trick is *not* a 
criteria to me. How 'handy' it was to write something - 
is not a criteria to me also. Perl is extremely 'handy'. I think 
if you write some random text - there is a big 
probability it will mean something reasonable to perl 
interpreter.

Your mileage may vary and when you see a built-in 
for-each in document() you may think " O! that's 
handy". 

When I see a built-in for-each in document() I think:

"This is *crazy* and I'll never use it. If I'll be remembering 
all the 'specific'  things ( AKA hacks ) about every tool 
I was using for last 10 years - I'll get ( more ) crazy 
and there will be no place in my head for knowledge 
about the *new* tools.  For 5+ years I was remembering 
the hex-code of Apple Lisa RET assembly instruction ... 
and many other 'useful things ...

The *only* possibility for me to stay in sync with new 
tools for a long time is to learn a new concepts, but not 
new hacks."

document() build-in for-each is either concept or hack. 
Is it a concept??? Concept of *what* then? Concept that 
you can mix multiple semantics into one magic word 
and call it 'handy' ? Been there, seen that many times 
in may tools. Can't remember such concept flying.

I don't want to learn hacks - there is no place in my head.

Your mileage may vary. I'm not saying and thinking that 
I'm 100% right. If somebody will show me what is 
a concept between built-in for-each - maybe I'll start 
liking document() monster -  like it was with 'no side effects'.
When I realized that it is actually 'access by value' - 
I changed my mind immediately. When I'm questioning 
others - I'm questioning myself as well. Sorry if it 
makes wrong impression. 

</background>



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]