Steve Eichert

Hey Steve,

Not sure how I missed your follow-up... Just saw it in my feed-reader a few minutes ago.

Anyway, thanks for the laugh and the smile :)

You might be interested to discover that I have been working a bit with your original sample, adding a few dynamic pieces to allow for setting the filters and source for filtering at run time, but otherwise left intact. In what little spare time I can afford at the moment I have been pulling it together into a sample app that integrates XSLT 2.0 Extension Functions and IronPython.

Still working on the integration part of this, which at the moment is planned to implement an extension function that calls your LINQ code from within an XSLT 2.0 transformation file, and upon return, transforms the result into an HTML report.

I've pulled the current state of things into a ClickOnce IP console app @ http://pypod.net/test/console/index.html

You'll need to access it from within IE the first time as there seem to be some issues at the moment with installing a ClickOnce app from Moz/Fx or Opera. Once installed,

>>> import test.linq_test

(you'll probably need to give permission for the app to access the internet, and then run the same command again.)

After accessing the changes.xml file, the result will begin streaming down you screen.

>>> import test.extf_test

Will dynamically access the transformation and data xml files from my XSLT GoogleCode based project, which will in turn access System.Math.Sqrt() and return the result of the input variable (hardcoded at 2 at the moment)

Add Powershell piping to the mix (via Jim's Powershell demo) and it seems to me that with Linq, XSLT 2.0+Extension Functions, Python, and Powershell piping, the possibilities are endless. :)

All of the source for this can be viewed @ http://dev.pypod.net/browser/trunk

and checked out of svn @ http://src.pypod.net/trunk

I'll be posting the above mentioned integration demo that outputs the HTML report just as soon as I can get a chance to finish up the last few pieces. When I do, I will point you to it to take a look at.

Regarding your point with Linq/XSLT -- I think you are spot on in your analysis. Adding to this a bit, to me the single most important factor that Linq brings to the table is that the 99% of the world who would rather chew on tin foil than program in XSLT can implement a significant portion of the data processing and transformation that XSLT offers them in a language syntax and style they already understand. Of course, there are things that Linq can to that go WELL BEYOND what XSLT 2.0 can do, and in some respects, vice versa.

To me, this is where the power of XSLT 2.0 extension functions really begins to shine -- Using XML-out/XML-in that, calling Linq-based code from within your transformation files which returns a specified set/sub-set of XML data to then continue in the transformation process, provides and amazing combination of power, function, and reusability of code which can be tied together in simple declarative XML files in which contain a sequence of internal and external functions to call, all of which can be piped together using a dynamic processing "control center" ala IP/Powershell.

If not obvious, I'm having the time of my life playing with all of these things at the moment.

Would LOVE to gain your imput on all of this, and how I might be able to make things even better :D

I'll post another comment when the mentioned demo is ready.

Wrong ClickOnce URI > http://pypod.net/test/console/publish.htm

Sorry 'bout that! :)

Sounds very cool! I can't wait to check it out (downloading now). I hadn't really thought about how sweet it will be to use Linq through XSLT extension functions. This is probably due to the fact that I'm out of touch with what's happening with XSLT, but it sure does sound cool! :)

Hey Steve,

I think the part of this that is the *coolest* comes with both the simplicity of implementation and reusability of the transformations files once they've been created. By this I mean that a simple XML node and child noes plus related attributes would then become your "scripting" language. For example,

<sqrt value="2" /> could be used to call the prefabricated XSLT 2.0 extension function, return the result for continued processing. Using a recursive approach,

<sqrt value="2">
<<sqrt value="parent::result" />
</sqrt>

Of course, all of this XML could be generated on the fly and fed into the transformation file via any .NET language, IronPython and Powershell providing a *FANTASTIC* Read-Eval-Print-Loop approach to writing applications for the .NET platform.

And if nothing else, its fun :D

the second sqrt element should obviously have only one < symbol. :D