This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
key(). ( Re: Saxon VS XT )
- To: xsl-list at mulberrytech dot com
- Subject: key(). ( Re: Saxon VS XT )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Fri, 04 Aug 2000 21:31:13 -0700
- Organization: The Qub Group
- References: <NDBBIHCDFEDDPMKFOFFKMEADDBAA.paulo.gaspar@krankikom.de>
- Reply-To: xsl-list at mulberrytech 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