Re: XSLT V 1.1

[Paul Tchistopolskii <paul@xxxxxxx>]

> >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.
> 
> Sorry, Paul, both should and does.  

I was thinking about more complex thing. Nevermind, pelase.
The rest of my letter and your answer shows that we 
both understand that this part of document is about bilt-in 
for-each.

> >And what's wrong with usage of intermediate variable ? 
> 
> I wasn't saying there was anything 'wrong' with using an intermediate
> variable.  However, there are four issues involved in using one:
> 
> Firstly, you can't do it in XSLT 1.0 without using extension functions and
> thus reducing the portability of your code.  I realise that that's probably
> not an issue in this thread as you are specifically talking about XSLT 1.1,
> but it is an indication of why document() *with* this functionality may
> have been included in XSLT 1.0.  Possibly if variables had generated node
> sets in the first place, then the powers that be would not have defined it
> in this way.

Are you still thinking in terms of Result Tree Fragment ? 
Why not forget about that fake and non-existant entity ?

XSLT 1.1 will remove it and RTF will become equal to node-set.  

I *do* understad why document() hack is included into XSLT 1.0 
( and I have said this in this thread for tree times. ) 

Yes, current document()  is masquerading lack 
of RTF -> node-set conversion. So what? RTF is gone, gone ...
forget it ... ;-) I'm not discussing XSLT v 1.0, but I'm 
discussing the nexts steps, let us be consistent.
 
> Secondly, it's more verbose.  The alternative code (given implicit
> rtf->node-set conversion) would be:
> 
> <xsl:variable name="docs">
>   <xsl:for-each select="class-files/file">
>     <xsl:copy-of select="document(@href)" />
>   </xsl:for-each>
> </xsl:variable>
> <xsl:for-each select="$docs/classes/class">
>   <xsl:sort select="@name" />
>   ...
> </xsl:for-each>
 
You are fighting for tersenness in XSLT ???? 

I think I should submit my XSLScript ( which is terse XSLT 
notation ) to W3C to make it W3C recommendation. 
And also I'l then ask for some[ +1 ] and a *lot* of other 
possible 'optimizations'. Just kidding. 

XSL is extremely verbose because of XML-ish syntax.
Each call-template contains a lot of overhead.
Missing 'else' is also *significant* overhead 
( and 'else' is *much* more common than 
document() !!!!!)

Call-template is *so* verbose that I already seen 
people asking for global variables AKA 'locals' to 
'workaround the tersennes of call-template verbosity' !!!

I'm glad you show to us that *just*  5 more extra lines 
allow you to get rid of document() hack and produce a clear, 
readable and supportable code for this exotics functionality.

> Of course the more verbose code may be regarded as a Good Thing.  There's
> always a balance to be drawn between readability and the size (and hence
> storage space and parse/processing time) of the stylesheet; different
> projects will have different priorities.

5 more lines !!!! Is it *really* worth hardcoding those 5 lines inside 
document() hack ???? 
 
> Thirdly, there are the issues of the base URI to be used for retrieving
> further information about the class files.  Let's say for the sake of
> argument that the class files themselves are in different directories and
> each have further references out - perhaps they point to a module
> definition - and that those references are relative to the class files
> themselves.
> 
> <module href="modules/module1.xml" />
> 
> In the initial code, the class nodes that are iterated over are within the
> initial document itself, and it is therefore possible to identify the base
> URI for resolving these references.  In the above variable declaration, on
> the other hand, a new RTF is generated - it's not *pointing to* the nodes,
> it's making a new copy of them.  

Why you think it should create a copy? It could not. As I said - 
every file ( XML or XSL ) which is processed by XSLT engine 
is always in the memory, this means you actually can live 
without creating a copy of something ( 'something' is already 
in the memory ) - but you can always create a pointer to that 
'something'. Why RTF can not be pointing  to the  nodes which 
are used to compose RTF? Yes, there is always some overhead 
for pointers e t.c. - Just to explain that in the world of 
XSLT 'copy' could be not a 'real' copy, but something more 
smart ( 'access by value' allows that ;-)

> It is therefore harder (if not impossible,
> depending on the XML schema) to tell what base URI should be used to
> resolve these references.

??? That's why I ask - could you pelase give the accurate usecase 
with filenames  e t.c ?  ( And please - take into account that 
my document() insists that relative URI's should be resolved 
relatively to the XML input, not to the stylesheet. )
 
> Finally, creating a copy of each of the documents involved means that, in a
> naive implementation at least, not only are the documents themselves
> stored, but so is a copy of each of them, which would presumably have an
> adverse effect on the memory consumption of the XSLT processor.

I see. You care about the efficiency of XSLT processors and you 
care about tersennes of XSLT. I give up. The only sound agrument 
against saxon:evaluate is " it will make XSLT engine more complex".

This is of course unbeatable agrument. It is of course easeir to 
pollute the core of XSLT engines with some 'handy shortcuts', 
create 'Trax' API and whatever else -  instead of implementing 
some efficient universal mechanizms, like saxon:evaluate.

> >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(). 
> [and snip explanation for bias against 'handiness']
> 
> I can quite see your point and can imagine how frustrating it must be to be
> presented with impenetrable code day after day.  As usual, the goal has to
> be to 'make the simple things easy and the complex things possible', for
> both the stylesheet author and the stylesheet maintainer.

Simple things are easy with *simple*  document() and complex 
things are possible with *simple* document().

Simple things are *not* easy with current document(), because 
just to load some document relatively to top-level XML input 
people should learn about "." , "/" and some other magic, because 
document() resiolves relative URIs relatively to the XSL stylesheet.

> Within XSLT 1.0 there is no way to convert a result tree fragment into a
> node set.  

I'm not talking about XSLT 1.0. Sorry for repeating this, but I don't 
even understand why we are discussing some craziness of 
XSLT  v 1.0 when the subject is XSLT V 1.1

'Backward compatibility' ? 'Legacy' ? Unbeatable again. 

But let us make it clear.

If the arguments against 'my' document() are :
"it could be not easy to implement it efficiently", 
"we have XSLT v 1.0 legacy"
e t.c. - this is one situation.

If "simple document() can not cope with this and that usecase " - 
this is another situation.

Let me notice that sofar there was *no* accurate usecases 
which could not be implemented on top of  my simplified 
document() V 2.0. 

As you show us - the drawback of removing hardcoded 
for-each is 5 more lines of clear XSL code.  I can live 
with that + it is also more general pattern than hardcoded
document() for-each, because hardcoded document() for-each 
solves only one aggregation scenario - but there are more 
other scenarios ( which are comparably frequent ). Let us start 
hardcoding some other scenarios into document() ? It will be 
'backward compatible', yeah ...   And ... wait ... At the 
end of your letter you *are* proposing exactly this!

< aside >

Jeni - I think you *are* perl hacker ( even you don't yet 
know it ) and I really suggest you try using perl. I think 
perl could become your language, because it supports 
your way of thinking. In perl you can easeily define a 
swiss knifes that will do multiple things at once. 
Writing perl one-liner instead of 2 pages of Java code!  
Consider perl, Jeni ! But you should but be prepared 
that it could take you up to 2 years to understand how 
to write *good* perl code. In perl it is very common that
first programms you are writing are 'extremely verbose'
( from the point of view of the person who has 2+ years 
of perl experience, and after 2 years you'l write 
the same code probably 5 times shorter. ) 
There are many not-obvious and 'powerfull' constructions 
which require reading many manuals describing 
those bells and whistles ( and they are of course 
changing many things.. occasionaly ... ) . That's 
what you want XSLT to be ;-)

< /aside >

> document() is not the only place where an implicit for-each
> takes place.  

I'm skipping the rest for now ( almost every usecase 
is worth thinking and I may write back later. Not in this 
thread ;-).

1.  You are pointing to some other places 
in XSLT which contain build-in for-each and RTF -> node-set.

RTF->node-set  is not an issue to me at all ( RTF is XSLT 
legacy entity with no sound rationale behind it. It is gone
and RTF->node-set will be required by XSLT 1.1 core, 
I think ).

Other examples of build-in for-each have no relation to 
the content aggregation, but are working around some Xpath 
problems ( and I think that finding better model for Xpath 
is not only doable, but it is unavoidable ). I see no relation 
to document(). 

Document() is *not* a part of Xpath specification, it is 
part of XSLT.

2. You are saying that user-defined Xpath functions 
could be a solution. I have not made my mind on this 
issue yet. I think another Xpath model is needed ( and 
will be unavoidable with support of Schema ), so ...
I feel it is all very far future.

I agree with your point that usecases that we, users
of XSLT,  have should influence the development of 
XSLT language.

The problem is that I can not remember this happening 
in the past and I don't see how the situation has changed, 
so I think this will all be like it was before.

<scenario name="Having fun with any W3C standard">

o Submit something to appropriate list ( XSL-list is 
a good place. Appears to be the only W3C  list with 
traffic ;-) ).

o Enjoy discussion with somebody who cares 
( that 'somebody' is rarely member of W3C WG )

o Depending on the personalities of particular 
W3C WG the discussion could influence the work 
of WG. More likely it will never influence the work 
of WG, no matter what is the level of your 
expertise and how much sense do your statements 
have.

</scenario>

<proof type="trivial">
There is no name of Michael Kay in 
E Acknowledgements (Non-Normative)
section of XSLT Recommendation, but there is plenty 
of other names there. Most of those names are unknown 
to me ( because I never seen in this list anything 
reasonable from those persons on XSLT ).
</proof>

Rgds.Paul.



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