Subject: Re: XPath's role (Was: Re: [xsl] Re: . in for) From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Tue, 8 Jan 2002 10:20:13 +0000 |
Hi Mike, > OK, I'll change the rules. Just because I was winning ;) > If removing range variables means that to achieve simple things, > people have to write recursive functions, then I'd rather keep range > variables! > > Two reasons: Usability and Optimization. You can argue with both, of > course, but I think the solutions using range variables are more > manageable both for implementors and for users, especially the sort > of users who've written a bit of SQL. Aren't the users who are familiar with SQL going to use XQuery rather than XSLT anyway? I think that our disagreement pivots on the fact that you have a different opinion of what the "simple things" are in XSLT than I do. You seem to think that the "simple things" that you'd want to do in XSLT includes joining two sequences in order to create a third node sequence, with the nodes in the result node sequence being nodes from the source tree. I think that you are very rarely required to do this in XSLT. I think that the choice is between: - a for expression that is more complex than it needs to be the vast majority of the time, but is relatively simple when handling a rare requirement - a simple mapping operator that handles the vast majority of cases very easily, but means you need to use recursive functions to handle a rare requirement To me, the latter is the winner based on the "easy things easy, hard things possible" argument. This argument rests on an estimate of the frequency with which you're required to do this join-of-two-sequences-to-create-a-third-that-holds-source-nodes operation. I think you probably would estimate this operation to be necessary (or desired) more frequently than I do. Part of that, I think, is because you're envisioning XSLT performing transformations that I think are much better suited to processing by XQuery. That's possibly due to a difference in opinion about the roles of XSLT and XQuery. You think (from what you've said elsewhere) that the ideal would be one language, and therefore XSLT should get as close to that language as possible by improving its support for querying data structures and its optimisability in general. I think that there's a requirement for two languages, and that therefore XSLT should focus on what it does best, which is being easy for non-programmers to use rather than being particularly great on performance, and handling document structures well. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XPath's role (Was: Re: [xsl] Re, David Carlisle | Thread | RE: [xsl] Re: . in for, Michael Kay |
RE: [xsl] How to calculate attribut, Michael Kay | Date | [xsl] text() and not(), Andrew Welch |
Month |