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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: result = node1 * node2 an, Dimitre Novatchev | Thread | RE: [xsl] Wishes for XSL revisions , Michael Kay |
[xsl] Re: result = node1 * node2 an, Dimitre Novatchev | Date | RE: [xsl] Wishes for XSL revisions , Michael Kay |
Month |