This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Wishes for XSL revisions ...
- From: "Michael Kay" <michael dot h dot kay at ntlworld dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Wed, 2 Jan 2002 11:21:03 -0000
- Subject: RE: [xsl] Wishes for XSL revisions ...
- Reply-to: xsl-list at lists dot mulberrytech dot com
> 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