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: Wed, 15 Sep 1999 15:25:30 -0400
Some experience of using XSL with HTML people. This message is not very
organized, sorry.

I have the enviable task :) of having to supervise 3 HTML (+some Javascript)
people to use XSLT over the last 2 months in a project. The major problems
for them are the 'weird' scoping of variables, the lack of a looping
construct, etc. I don't know about other people's experience but it seems
like even HTML people are more comfortable with procedural concepts than
functional concepts. The scoping concept they got after a few minutes of
explanation (and time for them to cool down :). The lack of a looping
construct they can live with since it is hard for them to understand the
matching rules as it is. When it is possible to avoid using recursion by
using apply-templates with a select attribute, that is always the preferred
solution for them.

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. They
just refused to use XSL for it and decided to use Javascript. With the book
"Calendrical Calculations", this has been solved beautifully (although I
will have to engineer a switch from lotus XSL 0.17.4 to 0.18.2 in order to
get it work properly). The math expression in XSLT is quite messy with all
the floor() and the sign with the DIV operator. It works.

2, Sorting of elements according to some arbitrary comparison rule. For
instance, after sorting according to dates, sort the elements according to
the list 'PGA', 'LPGA', 'Senior PGA', 'European Tour', in this order.
Personally I wish I have the same construct as in Perl where I just define a
sort template with syntax like:
  <xsl:sort select="@tour" comparison="golf-compare"/>
and something like
  <xsl:template name="golf-compare">
    <xsl:param name="a"/>
    <xsl:param name="b"/>
    <xsl:choose>
      <xsl:when test="a = 'PGA'">
        <xsl:value-of select="$a"/>
      </xsl:when>
      <xsl:when test="b = 'PGA'">
        <xsl:value-of select="$b"/>
      </xsl:when>
      <xsl:when test="a = 'LPGA'">
        <xsl:value-of select="$b"/>
      </xsl:when>
      <xsl:when test="b = 'LPGA'">
        <xsl:value-of select="$b"/>
      </xsl:when>
      <xsl:when test="a = 'Senior PGA'">
        <xsl:value-of select="$b"/>
      </xsl:when>
      <xsl:when test="b = 'Senior PGA'">
        <xsl:value-of select="$b"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$a"/>
      </xsl:otherwise>
  </xsl:template>

  With a top-level variable or some other device, I can actually make this
into something more generic for sorting any list of elements according to
the order in another list. With the current syntax, I don't know how to do
that. Did I miss something here? Is it possible to use keys to do this?

I have been pleasantly surprised by the amount of hard questions coming from
them. I thought it would be a lot more. But the frustration level has been
very high and staying high for a long time.

As the work progresses, we are encountering another problem: XSLT is very
verbose. And the templates for real-life transformations are very messy,
especially since we are converting to HTML without CSS (I am not getting
into a discussion about CSS). Attributes for tables are messy and hard to
group using attribute groups because all tables are basically different in
size and other attributes since they are used for formatting of the pages
rather than presentation purposes. So, it is sometimes difficult for me to
read the templates and follow the logic. This problem every lisp programmer
knows: too many defuns. Although we don't use many named templates and
therefore naming is still okay so far, the problem is even harder as most
templates are nameless and I must rely on the comments to figure out the
function of the templates. It would be nice if templates can somehow be
grouped together into a module or something. (Hmmm... may be something like
XSLT as decorations on XML Schema of the XML files... That would be easier
for me to ensure all elements have been taken care of too.) Ease of
maintenance will be one of my criteria to decide whether we will be doing
XSL in this scale again.

We have a few thousand lines of XSL code (with common code factored out to
be xsl:included) and it is growing rapidly. My fingers are firmly crossed.

Khun Yee

-----Original Message-----
From: Sara Mitchell [mailto:smitchel@xxxxxxxxxx]
Sent: Wednesday, September 15, 1999 10:25 AM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: What will be the future improvements of XSLT?


No, you're not weird. I also find XSL far less puzzling than
javascript. I personally think that the discussions (or 
is it controversy?) over whether XSL is 'too difficult' or
not depends almost exclusively on what the person's previous
background is in.

Sara

David Carlisle wrote:
> 
> > I think also that somebody who can manage HTML with a little JavaScript,
> > even given a small subset a XSL, will surely be puzzled by such a
> > declarative language.
> 
> Why should this be?
> 
> I find XSL far far less puzzling than javascript. Am I really weird?
> 
> David
> 
>  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


Current Thread