Re: [xsl] Wishes for XSL revisions ...

[Trevor Nash <tcn@xxxxxxxxxxxxx>]

Gunther,

On Wed, 26 Dec 2001 21:58:33 -0500, you wrote:

>Dear XSL designers/maintainers, please scrutinize your
>specification for orthogonality or lack thereof. I think
>you have put in too many special limitations. Here is a
>list of some:
>
I do not speak for the XSL designers, these are my opinions only:
I think you will find XSLT2.0 interesting reading: here is a list of
references which Mike Kay posted here recently:
>For reference, here's a list of the specs:
>
>- XSLT 2.0:
>  http://www.w3.org/TR/xslt20/
>- XPath 2.0
>  http://www.w3.org/TR/xpath20/
>- XQuery 1.0
>  http://www.w3.org/TR/xquery/
>- data model for XQuery and XPath
>  http://www.w3.org/TR/query-datamodel/
>- functions and operators for XQuery and XPath
>  http://www.w3.org/TR/xquery-operators/

Gunther wrote:
>- result tree fragment is not a node set, requiring the node
>   set function that just about anyone supplies but which
>   produces only hassles figuring out what namespace this
>   node-set function is in.
>
With hindsight, I think most people agree this one was a mistake.  It
is fixed in XSLT 2.0.  Look at www.exslt.org for a way of using such
extensions to XSLT1.0 in a more portable way.

>- call-template has no mode attribute
>
I do not think it needs one.  Templates are selected either by
match+mode+priority with apply-templates, or by name with
call-template.  A template called by name may have match+mode
attributes too, but those are not used in selecting which template to
call: it must be uniquely identified by name.  If call-template did
have a mode attribute, what do you think it should mean?

>- Why should it be forbidden to construct the name of a template
>   to call?
>
>- Why should it be forbidden to construct the mode
>   argument?
>
>- Why should any qname have to be hard-coded?
>
You should remember that XSLT is designed to be compilable, so you
should compare it with C or Java rather than Javascript for example.
These things make more work for the language implementor, and make it
near impossible to invent good optimisations.  These things might make
the language easier to use, but you would pay through transformations
taking longer to run.  Programs with names constructed at run time are
also much harder to maintain and less likely to be robust.

Another aim of the original lnguage was to make it possible to write
an incremental processor, i.e. one that could see a change to the
input tree and make the corresponding change to the output tree
without reprocessing the whole thing.  All of your complaints could be
explained by that.

I have written a lot of complex XSLT, and have never been stopped yet
from doing anything I needed to do through lack of these facilities:
there are other ways to do the same thing.  For example, look in the
archive for this list for 'generic templates'.

>This only forces awkward choice forms onto the style sheet
>programmer where things could be done soo much simpler!
>
>I will probably have more of those as I go. If you make XSL
>a functional language, why don't you go all the way?
>
I think there are two parts to that:

1. It is still difficult to implement a pure functional language
efficiently: some things are going to be slow however good the
compiler is.  If you make it too difficult you end up with a great
language but few or no compilers (Eiffel went that way).

2. The target audience for XSLT is not computer scientists or even
programmers, but Web designers.  [[I do not intend any insult to Web
designers here - I am just recognising that different people with
different backgrounds with have varying difficulty assimilating new
ideas]]  There seems to have been a view that these folk might have
trouble with a too-pure functional language.  
I'm not sure that was right - looking at the questions on this list it
seems to be the programmers who are most easily confused.  Top of the
list seems to be variables whose value cannot be changed and for loops
which aren't.

>regards
>-Gunther

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list