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

Subject: RE: [xsl] Wishes for XSL revisions ...
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Wed, 2 Jan 2002 11:21:03 -0000
> 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:
>
> - 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.

This deficiency has been recognized for a long time, it was fixed in the
XSLT 1.1 working draft and the fix has been carried forward to the XSLT 2.0
working draft.
>
> - call-template has no mode attribute

Why would you want one?
>
> - Why should it be forbidden to construct the name of a template
>    to call?

This isn't a question of orthogonality in the language, it's a question of
what is done statically and what is done dynamically. There's an arguable
case that XSLT should be a more dynamic language, but there is also an
arguable case for the status quo. The more the behavior of a stylesheet can
be understood statically, there more scope there is for optimization.
>
> - Why should it be forbidden to construct the mode
>    argument?

For the same reasons.
>
> - Why should any qname have to be hard-coded?
>
For the same reasons.

> 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 don't think there's anything intrinsic about functional languages that
says they have to be dynamic (e.g. in the sense of providing the ability to
call a function whose name is specified as a string at run-time). In fact,
if "wishing to make XSLT a functional language" were a design goal, that
would take us in a different direction, towards supporting functions as
first-class objects in the type system, and allowing higher-order function
calls - probably a cleaner solution to your requirements than the one you
propose.

Mike Kay


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


Current Thread