RE: What will be the future improvements of XSLT?

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