key(). ( Re: Saxon VS XT )

[Paul Tchistopolskii <paul at qub dot com>]

> I think he was kidding.

Not realy. The point is that I think there is almost no 
need in 'special support of hashtables'  in XSLT, because :

1. node-set itself is already kind of hashtable.
2. I don't think  that  when making  <xsl:value-of select="./foo"> 
the underlying engine code enumerates each child  
with if ( string.equals("foo") )

I mean that XSLT already has some 'built-in' mechanizms 
which are very close to "hashtable support".

Even your words about XT-fanatizm are reasonable
( and I agree that I'm sometimes too emotional when it 
comes to tools  and I wish all my opponents forgive me 
for this ) , unfortunately the problem is that this is 
not the case with key().

After spending some time with Sebastian's sample 
I still think that key() is not a good thing ( I'm 100% sure 
than  document() with 2 parameters is also not a good 
thing ), because it results in the code which is hard for 
reading. Try looking inside Sebastian's  test6.xsl and try 
to understand what the code does *not* looking into the 
.xml file. I think it will take some time, no matter how 
experienced you are with XSLT. It is very much like 
that 'select bla-bla from dual' instead of simple 
'autoincrement'  ;-) By the way - Sebastian's code is 
*very* clear. It is the 'key()' stuff which is messy. 

Because the thread become hotter than it should be, today I 
have spent some time preparing the simplistic solution 
( at the moment I have 2 ) to show that there is 
no need in key() in test6.xsl.  There are some surprizes, 
because I suddenly found that for some reason some Xpath 
expressions suddenly become extremely slow ( up  to five-ten 
times slower )  when I add some simple predicate that should 
*not* have such impact.
 
I'm now investigating what happens with latest version of SAXON 
and XT and if  my kids will not cry too much till the weeekend I think 
that I'l get a 'simple workaround'  for test6.xsl much faster than 
in 2 weeks. 2 weeks is to solve the 'entire' problem ( the 'entire' 
problem is the weakness of hierarhical model in comparsion 
to relational.)

Rgds.Paul.

PS. I suggest to look at Sebastians 'tests' I think it is a pity that 
the task which is *trivial* if placing it into relational model becomes 
so horrible when trying to 'do it all with 'XML-only'  way' . 
Really.  Even my old and ill PXSLServlet can provide 
all those views for the cost of nothing, just a bunch of 'order by's' - 
and no problem *at all*. But because saying to Sebastian  
"Sebastian, you should start using my tool"  is something I 
don't think I'l ever say - I'm now trying to find something simpler ;-)

PPS. key() is a 'road-sign' people are using to speed-up 
the processing of some things. This is a bad thing 
when compiler requires  *user*  to provide such a roadsign.
Right?

Or there is some other meaning behind key() ? What is that 
meaning ? ( Maybe I'm stupid, but  the explanation with the 
words 'hashtable support' is not the explanation to me at all. 
Nodeset itself  is a hashtable. In XML every node is a 
hashtable-of-hashtables. The entire XSLT is about processing 
huge hashtables ( AKA XML files  AKA node-sets )).

> > >Poor C, ( and Pascal )  they  had no build-in hashtable support.
> > Red herring
> > You don't need built-in support to create a hashtable in C it's so simple.
> >
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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