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

Subject: Re: Can solve the N-queens - but can't count!
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 17 Jun 1999 15:23:12 +0200
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. Consider:

<xsl:template match="/">
    <xsl:variable name="global-test">
        <xsl:if test="//A">true</xsl:if>
    </xsl:variable>
    <xsl:apply-templates select="*">
        <xsl:param name="global-test" expr="$global-test"/>
    </xsl:apply-templates>
</xsl:template>

Adding an 'A' element anywhere in the input tree would, in principle,
require that the whole output tree be recomputed. Also consider that the
variable could have been set to an expression of arbitrary complexity - up
to and including to the results of running a turing machine based on the
input tree.

I fail to see how multiple passes could make things worse. In fact, one can
already simulate multiple passes today by representing the result tree
fragment as a string with appropriate encoding and simulate all tree passes
by using string expressions. Horrible hack, certainly. But if we are already
accepting that XSL today supports constructs which incremental
implementations will never handle, it ceases to be an overriding argument.
Instead we should concern ourselves with the question of whether the new
feature is benefitial for XSLT stylesheet writers.

>However, XSLT is designed so that this restriction can be relaxed in the
>future (ie you can extend XSLT to allow multi-pass transformations
>simply by treating a result tree fragment as a node-set containing a
>single root node).


There is that. This could form the basis for a "level of implementation" of
XSLT. That's not too good, but is better then having all sorts of
incompatible extensions in different processors.

>> BTW, I tried ... What am I doing wrong?
>
>Failing to email me a proper bug report including the complete
>stylesheet and source document.


You are right, of course. Now that I know it is actually bug, I'll do so
immediately.

Have fun,

    Oren Ben-Kiki


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


Current Thread