[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT V 1.1

Subject: Re: XSLT V 1.1
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Fri, 15 Sep 2000 21:18:00 -0700
tc hackers download
----- Original Message ----- 
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>

> 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.