[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
key(). ( Re: Saxon VS XT )
Subject: key(). ( Re: Saxon VS XT ) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Fri, 04 Aug 2000 21:31:13 -0700 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Saxon VS XT, Paulo Gaspar | Thread | RE: key(). ( Re: Saxon VS XT ), Paulo Gaspar |
RE: <xsl:stylesheet xmlns..., Paulo Gaspar | Date | Re: <xsl:stylesheet xmlns..., Paul Tchistopolskii |
Month |