- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 15 Apr 2009 16:54:47 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5023 --- Comment #16 from Dave Peterson <davep@iit.edu> 2009-04-15 16:54:47 --- (In reply to comment #13) > i think assumptions about optimizations built into processors are a bit > optimistic. for example, a very obvious optimization in the space of XML > implementations would be to use xsl:key for building an index, but recently i > ran into an XSLT processor (in a highly successful commercial product, XML > Spy), which does not seem to do so. i am not sure, but the performance really > looked as if they treated every key() call as a search of the document tree. (Andy to comment #14) > The fact that XML Spy is so successful despite its allegedly poor performance > is a good reminder that as technology providers, we often over-estimate the > importance of performance to our users. At one point I used XMLSpy to edit the Schema spec, but on a document that large, it was indeed unusably slow. The XMLSpy folk told me they specifically designed their product for use on lots of small documents rather than one or a few a large ones. > (However, the post you cite provides no evidence that XML Spy doesn't using > hashing or indexing to support xsl:key - it seems to be pure conjecture. Such > conjectures by users are often way off the mark, in my experience.) I don't see that Erik Wilde mad any claim about how XMLSpy actually supports xsl:key. Only that it ran slowly when he used it to process xsl:key instances "as if" they ran repeated searches of the document tree. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 15 April 2009 16:55:00 UTC