I wish to post our correspondence with Niklas Lindstrom which somehow happened to take place out of the list, but I find it interesting enough to be included. It's 4 messages from Niklas and 3 replies. Any comments are welcome. Tom Kaiser -------- Original Message (#1) -------- Subject: greetings Date: Tue, 09 May 2000 14:25:58 +0200 From: Niklas Lindström <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] An initial greeting! I've stumbled upon your projects only a few minutes ago; but I'm impressed. I use XSLT both for commercial purposes at work, and in theory in any application I might develop. Currently, there are only a few xslt-processors I've tested, and although XT is the most remarkable (but not the most compliant) one, I'm always on the lookout for something fresh. And this seems to me to be just that. Especially the perl-bindings attract me. (Not to mention the GPL.) Unfortunately I'm not able to give any programming support, but I'd like to voice to you my interest, and best wishes. I'll try out all you offer as soon as possible. The only thing I know can "offer" - apart from testing - is wishing; and maybe having someone on your back begging for improved functionality is not that compelling. Anyway; I'm very interested. Best regards Niklas Lindström @ valtech.se -------- Original Message (#2) -------- Subject: Re: greetings Date: Tue, 09 May 2000 15:11:42 +0200 From: Kaiserovi <[EMAIL PROTECTED]> To: Niklas Lindström <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Dear Niklas, thanks for encouragement! It was a pleasure to read your letter. Please do feel free to make any comments and wishes for extensions. It's necessary to be aware of the fact that Sablotron does not yet conform to the XSLT spec. Details can be found in the Sablotron documentation (at www.gingerall.com, under "Library"). There's still a plenty to be done. Any help with testing would of course be absolutely welcome. Also, if you work with XSLT a lot, you may know better which features should be added before others, and which would come in handy even though they aren't in the spec. So please keep in touch, Tom Kaiser -------- Original Message (#3) -------- Subject: Re: greetings Date: Tue, 09 May 2000 16:01:00 +0200 From: Niklas Lindström <[EMAIL PROTECTED]> To: Kaiserovi <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Hello Tom! Thank you for the quick reply. I'm glad to hear that my feedback might be of use. Is this the adress I should reply to, or shall I use <[EMAIL PROTECTED]>? (I have also subscribed to the mailing list.) I understand that this is not yed fully developed, and I hope my comments and suggestions about what I feel is most useful in the xslt-specs will help out. I just begin with some thoughts about important features not yet supported. This is just an outburst of thoughts; if it's too extensive, or too incomprehensible, please reply with eventual questions. I should be able to find the necessary parts in the W3C-spec implicitly referenced to if you want. The list is arranged in "topmost -> most important"-order. Here goes: 1) Using predicates in matches is essential in the stylesheets I've developed. My guess is that this is something you're already working on though. 2) The "current()"-function has proven to be of much use in my projects, as it provides an easy way to make matches when using cross-referenced xml. Although the "key()"-function and "xsl:key"-element are intended to to this, I suppose those are a bit more complicated to implement. See 4) for more about that though. 3) I hope both "name"- and "match"-attributes are allowed at the same time in the "template"-element; as this is very useful sometimes. Furthermore, I hope variables and parameters can contain result-tree-fragments. I sometimes use named templates as "containers" around an output-tree constructed inside an "with-param". 4) As I mentioned in 2), the "key"-functionality simplifies and (hopefully) speeds up cross-referenced xml. XT does not implement this, but both Saxon's and Xalan's performance seem to increase with up to 400% on occasions, when this is used wisely. (Don't fully trust my benchmarks though..) 6) The "copy"-element is necessary (as far as I know) to make stylesheets which lets through all (or chosen) xml, using specified templates to relabel or rearrange data which requires new semantics. (Extremely useful when you in the middle of a project realize that some 200 documents should be slightly rephrased to fit a more well-formulated dtd or likewise.) 7) Currently, I allow namespace-declared arbitrary xml in my stylesheets. This is for two purposes. One is purely meta -- comment-attributes and xml-marked documentation for instance--, the other is for referential xml (such as form-specific tables with references to "raw" xml), which should be possible to reach via an empty "document()"-call (returning the current stylesheet). In XT I have to use the filename of the stylesheet though (and could therefore just as easy use an auxiliary xml-file for such data. (But I personally find this approach more convenient.) 8) One nice feature in Xalan is that it accepts the old ns for xsl: "http://www.w3.org/XSL/Transform/1.0", simply throughing a warning when it is used. As XT is so old it does not accept the correct (only this old one), all my stylesheets must be slighly modified to work in most new transformers. That's all I came up with now, be it much or not. If I have the time, I may try to write some small xsl (and complementing xml) that uses all of the functionality above. -- best regards Niklas Lindström -------- Original Message (#4) -------- Subject: Re: greetings Date: Wed, 10 May 2000 16:41:09 +0200 From: Kaiserovi <[EMAIL PROTECTED]> To: Niklas Lindström <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Niklas, many thanks for the suggestions. I agree with all you say. The match predicates, current() and xsl:copy are obviously the things to fill in now. As for 3), name and match can appear together. 4) xsl:key... well, this is harder. See below. 8) the "obsolete URI" warning is a good idea; I also thought one might issue a warning when someone declares a 'xsl' namespace with a URI that's different from the XSLT one. I didn't get 7): > 7) Currently, I allow namespace-declared arbitrary xml in my stylesheets. > This is for two purposes. One is purely meta -- comment-attributes and > xml-marked documentation for instance--, the other is for referential xml > (such as form-specific tables with references to "raw" xml), which should be > possible to reach via an empty "document()"-call (returning the current > stylesheet). In XT I have to use the filename of the stylesheet though (and > could therefore just as easy use an auxiliary xml-file for such data. (But I > personally find this approach more convenient.) You have mentioned xsl:key; this is one of the several shortcomings of a more difficult nature. The others are the lack of xsl:number, xsl:sort, xsl:output, and xsl:import. Actually this was a very exact observation of someone at the XSL-List. This will take some work. > If I have the time, I may > try to write some small xsl (and complementing xml) that uses all of the > functionality above. That'd be great, we do need testing code. BTW do you use any test suites or benchmarks to check the performance of XSLT processors? As to the addresses, I suggest to use the mailing list (sablist@...). May I post your last message there? Best, Tom -------- Original Message (#5) -------- Subject: Re: greetings Date: Thu, 11 May 2000 11:35:35 +0200 From: Niklas Lindström <[EMAIL PROTECTED]> To: Kaiserovi <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Hi Tom! In the future, I'll use the xsl-list for all these postings. Please do post my previous mail(s) there if you wish. Hopefully I can elaborate on the remaining issues from your reply (e.g. concerning point #7 ) soon; and come up with some xsl:s and xml:s for testing. As for benchmarking: I haven't done something thorough unfortunately; just timed some processors with a primitive perl-script. It seems that XT is the quickest yet though, followed by Saxon. Xalan is much slower; but it provides some interesting parsing and timing information per default, making it quite useful when meassuring different transforming approaches. I have not timed any of these in a server environment though, only at the command-line. regards Niklas -------- Original Message (#6) -------- Subject: Re: greetings Date: Thu, 11 May 2000 12:00:00 +0200 From: Kaiserovi <[EMAIL PROTECTED]> To: Niklas Lindström <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Niklas, thanks for the message. > In the future, I'll use the xsl-list for all these postings. ... Are we referring to the same list? I meant the Sablotron mailing list, whereas this looks more like the XSL-List at Mulberry... Sorry if I confused you. The Sablotron list is at [EMAIL PROTECTED] > As for benchmarking: I haven't done something thorough unfortunately; just timed > some processors with a primitive perl-script. It seems that XT is the quickest yet > though, followed by Saxon. ... Yes, XT is surprisingly fast. BTW it was the one I tested the debug version of our processor against. I was shocked to find XT MUCH faster. That was because of the debugging support slow-down, though. XT still tends to be faster, but it's not by much, and we have some optimizations up our sleeve. That's what the benchmark tests would come in handy for. Providing the timing information is a good idea. Best, Tom -------- Original Message (#7) -------- Subject: Re: greetings Date: Thu, 11 May 2000 13:09:07 +0200 From: Niklas Lindström <[EMAIL PROTECTED]> To: Kaiserovi <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Hello! > Are we referring to the same list? I meant the Sablotron mailing list, > whereas this looks more like the XSL-List at Mulberry... Sorry if I > confused you. The Sablotron list is at [EMAIL PROTECTED] No worries, it was the sablotron-list I had in mind. I have subscribed to it, but have yet not got anything from it. Is it something wrong, or simply no new postings the last 2-3 days? Anyway, I shall use it for further relating issues. > Yes, XT is surprisingly fast. BTW it was the one I tested the debug > version of our processor against. I was shocked to find XT MUCH faster. > That was because of the debugging support slow-down, though. XT still > tends to be faster, but it's not by much, and we have some optimizations > up our sleeve. That's what the benchmark tests would come in handy for. I see. It'll be very interesting to see what will happen. I'm amazed at xt:s speed to; I wonder how it works, since it remains to be the quickest processor available (or have I overlooked someone faster? Not to mention the upcoming versions of Sablotron, of course.. ;) ). As for timings: I've used some vastly processing-demanding transformations (using much cross-referencing, for one), most heavy being one with an xml of some 500kb, taking up to a couple of minutes(!) to transform. These things took probably 2 times the time with Saxon, although the use of keys made it around 5 times faster. Here are some unproffessional measurements: ---- java xt (without xsl:key): 79 s xt [exe] (without xsl:key): 39 s java saxon (without xsl:key): 164 s java saxon (with xsl:key): 38 s saxon [exe] (without xsl:key): 81 s (? I mixed up some results once) saxon [exe] (with xsl:key): 22 s java xalan (without xsl:key): 482 s java xalan (with xsl:key): 356 s *[exe] means windows executables; whom still require the JVM.. ---- You may post this whole thread if you wish; perhaps that's the best way to continue this in the list. regards Niklas
