Re: Can solve the N-queens - but can't count!

[James Clark <jjc@xxxxxxxxxx>]

Oren Ben-Kiki wrote:
> 
> James Clark <jjc@xxxxxxxxxx> wrote:
> 
> >If XSLT allowed you do anything with result tree fragments that you can
> >do with source node sets, then you would in effect be able to do
> >multi-pass processing in XSLT:
> 
> >...
> >Whilst this would be very powerful, there is concern that this would
> >make infeasible to create incremental, interactive implementations.
> 
> I'm not certain they are feasable today.

I wouldn't assesss the feasibility of such implementations on the basis
of whether it's possible to create cases that such implementations will
handle very inefficiently: I don't think it's possible to create a
transformation language that does what XSLT needs to be able to do and
yet does not permit such cases.  I would instead assess the feasibility
on the basis of how well the implementation does for typical
stylesheets, how well it does on average.  This is very hard to
quantify.  There are lots of things in XSLT today that probably make an
incremental implementation harder: xsl:for-each, modes, named templates,
parameters, local variables, absolute location paths, upwards and
sideways axes (ie axes other than descendants and children), result tree
fragment values for parameters and variables.  Making a judgement about
where to draw the line is hard.  I'll freely admit that I'm worried
about whether XSLT has drawn the line in the right place, but my worry
is not that we've left things out but rather that we've gone too far and
put too much in.  However I have a hard time thinking of things that I
would be willing to see left out of the current WD.

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list