[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Wishes for XSL revisions ...

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

Mike Kay

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.