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

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