Subject: RE: What will be the future improvements of XSLT? From: Khun Yee Fung <kyeefung@xxxxxxxxxx> Date: Thu, 16 Sep 1999 10:29:30 -0400 |
> So far, the most difficult problems for me to solve are: > 1, Drawing a calendar as a table given only the year and the month. A solution to that one was posted on this list a week or so ago. The formula in the book turns out to be simpler. > 2, Sorting of elements according sort template with syntax like: <xsl:sort select="golf-order(@tour)"/> with golf-order being an extension function that mapped from your enumerated type to the integers. I am trying very hard not to use extension functions. I started using Perl (v.3) more than 9 years ago to avoid sh+sed+awk. I am going to fight very hard not to go down that (mix-and-match in the same file, nightmare maintenance) road. Going back to the original question; other than using extension functions, can I do this kind of sorting in XSLT at all? > XSLT is very verbose If the world doesn't move to XML as being predicted, XSLT is anyway lost. If it does, then verbosity will be a general fact of life. If you use an XML editor which can hide some of the XML details then this isn't so much of an issue. Verbosity is not an issue with the XML (document) files. Verbosity is an issue for me when it comes to programming. Too much and it is difficult to digest (one page of XSLT code does not do as much as one page of C++ or Java code). Too little and it becomes Perl and again tough to maintain. It will be very interesting to find out how the many XSLT files that we have will be maintained by the production staff. > and I must rely on the comments to figure out the > function of the templates. Your XSLT file is an XML document, you can put in structured comments marked up from another namespace, html, docbook, whatever, and then tell the xslt processor to ignore that namespace. Sure. But I still have to read the comments. If the guys do not put in comments properly and heaven forbids put in inaccurate comments, I still have to read the code. Nothing special here. It happens to all programming languages, except that in other languages I can sort of guess what a function or a class does by its name and in XSLT I have to parse the match attribute to find out what the template is matching. Code inspection, when it comes, is going to hilarious (for me, not for them. Good time to test their XSLT knowledge :). But the point is that we are using HTML people to do XSLT and not Java programmers to manipulate the DOM tree (which I'd rather be doing for its flexibility). Hiring good Java programmers has been very difficult. It was the clinching factor for us. I like a lot of features in XSLT. Khun Yee XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: What will be the future improve, DPawson | Thread | Re: What will be the future improve, David Carlisle |
Re: document() question, G. Ken Holman | Date | RE: What will be the future improve, Kay Michael |
Month |