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

Re: XPath's role (Was: Re: Re: . in for)

Subject: Re: XPath's role (Was: Re: Re: . in for)
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Tue, 8 Jan 2002 10:20:13 +0000
Re: XPath's role (Was: Re:  Re: . in for)
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
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.



Jeni Tennison

 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.