My last post was about how the .NET framework (through 4.0) does not support XSLT 2.0, only XSLT 1.0. And, that I had to leverage a third party library for an XSLT 2.0 processor. That's not so bad, and the Saxon processor is working out quite nicely for .NET.
So, of course, that couldn't just be the end of the story. The latest WS-I test tools are written in XSLT 2.0, but the stylesheet to render the report in, say, a web browser uses XSLT 1.0. This is probably as-designed, in order to support a wide range of web-browsers that would load the raw XML report with the stylesheet reference in it (rather than a report that has been pre-rendered to HTML).... read more
Well that stinks. The WS-I authored tool suite is really a collection of eXstensible Stylesheet Language (XSL) files that execute XSL Tranforms (XSLT). That's actually okay. What stinks is the fact that the tool suite developers chose to write their tools in XSLT 2.x versus 1.x. Okay that doesn't stink either.
What stinks is that the out of the box System.Xml.Xsl namespace (at least in .NET 4.0) does not support XSLT 2.x. So essentially, I can't use the stock .NET framework to execute the transform workflow.... read more
Hi again. This is yet another project I am starting in order to tinker with new technologies and fill voids in the universe of software. One such void I recently happened upon was testing tools for WS-I compliance checking. Through version 1.1 of the Basic Profile, and related profiles, the WS-I released tools to perform conformance checking as Java code. They are okay to use, and are leveraged by common web-service and XML development tools.... read more