[xsl] Re: Re: On XSLT 2.0 Writing Styles

Subject: [xsl] Re: Re: On XSLT 2.0 Writing Styles
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Sat, 11 Oct 2003 19:55:51 +0200
Thank you, Mike.

It is rare to see such a deep analysis on this topic -- I hope it will find
its place in the XSLT FAQ.

Apart from purely stylistic reasons, I have found one case where the XSLT
style simply cannot be transformed completely into the non-xml style. This
happens, when we need to define and use variables, whose value is a

The variables that can be defined in an XPath expression are of the form:

  for $someVar in $XPathExpression return

and it works when we need a variable with atomic value.

However, it is not possible using the above syntax to define a variable,
whose value is a sequence.

Thus, if I would need to have my code in a single XPath expression, I would
have to write:

         <xsl:sequence select=
              "f:scanIter($arg1 - 1, $arg2, $arg3)
               f:apply($arg2, f:scanIter($arg1 - 1, $arg2, $arg3)[last()])"

because f:scanIter() returns a sequence and it is impossible to write:

         "for $vIterMinus in f:scanIter($arg1 - 1, $arg2, $arg3) return
               $vIterMinus, f:apply($arg2, $vIterMinus[last()])"

But writing the first expression above will cause

    f:scanIter($arg1 - 1, $arg2, $arg3)

to be calculated twice.

Therefore, the more efficient way to express this is using XSLT-style:

         <xsl:variable name="vIterMinus"
                       select="f:scanIter($arg1 - 1, $arg2, $arg3)"/>

         <xsl:sequence select=
          "$vIterMinus, f:apply($arg2, $vIterMinus[last()])"/>

Thank you once again for this nice discussion.


Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

"Michael Kay" <mhk@xxxxxxxxx> wrote in message
> >
> > I understand this as personal preference or is this
> > preference based on some objective criteria?
> It's based on instinctive judgements about the engineering quality of
> the code, but it's far too early to judge whether my instincts are
> right.
> >
> > I would appreciate your opinion on how do these two styles -- 
> > long (20-line
> > +) XPath expressions versus xslt-structured style --  score in
> > +readability,
> > compactness, flexibility, efficiency and maintainability.
> There has been an ongoing debate about the merits of using XML syntax
> versus non-XML syntax for a while now, and I don't think it's going to
> go away. It promises to be one of these perennials like "elements vs
> attributes".
> Some people seem to take an instinctive dislike to having attributes in
> an XML document whose content is 20 lines long. Part of the rationale is
> that the newlines don't survive XML parsing, but the newlines are
> essential to the readability of the code.
> I think it's going to be quite unusual to see XQuery parsers that report
> more than one syntax error in a single compile run. The grammar is not
> robust enough to allow easy recovery from syntax errors, though the
> introduction of semicolons as separators in the latest draft helps.
> Reporting multiple errors in XSLT is easy because of the 3-phase parsing
> approach (XML parsing first, then XSLT, then XPath). This gives a
> definite advantage when you're doing something on the DocBook scale.
> >
> > In other words, why should we prefer the "XSLT style" to the
> > "XQuery style"?
> >
> I think the advantages of an XML-based syntax are:
> (a) it's useful where the stylesheet includes large chunks of stuff to
> copy into the result document
> (b) it's useful when you want to transform stylesheets or to do any kind
> of reflection or introspection
> (c) it reuses all the XML machinery such as character encodings, base
> URIs, entity references
> (d) it's much easier to provide user or vendor extensions to the
> language in a controlled way.
> But there's no doubt that the XQuery style makes it much easier to write
> short queries.
> Michael Kay
>  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