On Tuesday, March 18, 2003, at 10:59 AM, Matt Sergeant wrote: <snip>
Well, XSP is dynamic. So in order to know when the output changes you'd have to be able to follow the path of the code before it is executed. Which is basically the halting problem.
Ahh - I see our confusion. I agree that you can't cache the output of XSP because it is dynamic, but Tod's original statement was that having an XSP page generated later in the pipeline results in the page having to be recompiled to a perl module every time. However, as long as the source XSP comes from a reproducible source (eg. XSLT transform) then it should be theoretically possible to cache the compiled module.
Interestingly, this would suggest to me that it would be much more inefficient to have XSP earlier in the pipeline - since nothing after it can be cached.
<snip>
On your namespace thing, I suspect this can be alleviated with some changes to your XSLT to suppress or properly output XML namespaces, but I don't have my XSLT books to hand to figure this one out. Perhaps some XSLT gurus here on the list can help.
Ok. I entirely agree that my XSLT page is broken and should be fixed. I think the XSLT processor is probably doing the right thing by resetting the xmlns (although having it reset to empty is annoying - but I don't think there's an alternative).
However there is definitely still a bug if the XSP processor crashes when there is an empty xmlns element. Eg. this .xsp page dies for me:
<xsp:page language="Perl" xmlns:xsp="http://www.apache.org/1999/XSP/Core";>
<blah xmlns=""/>
</xsp:page>
Thanks for your efforts!
Regards, Chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
