key(). ( Re: Saxon VS XT )
> 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format