Re: [xsl] 'nother xslt2 engine

Subject: Re: [xsl] 'nother xslt2 engine
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Mon, 15 Nov 2004 16:28:18 -0800
Michael Kay wrote:

It's not schema-aware.

I discovered this same info after looking through there site... I did'nt see any direct reference as to their plans in this regard but I did'nt do a thourough scan either...

XPath 2.0 Functions Support <snip/>


XSLT 2.0 Functions Support <snip/>


Is there a real benefit in releasing a so called XSLT 2.0 processor that is not fully compliant with the draft you released over a year ago AND with several 1.0 based elements and functions from the 1.0 draft released in 1999 missing as well! Releasing a press release suggesting intent to deliver is one thing but with a specification that, as you suggested last Auguest, may not reach final recommendation for at least another year I am having a hard time understanding why a release with so much of the Nov 2003 specification missing would not be at VERY LEAST labeled an early beta at best and more realistically an alpha release.

Altova, you have plenty of time to do this right... why not take it? As a developer interested in writing XSLT 2.0 stylesheets I would have a hard time looking at a half-baked processor to play around with when I could use a fully-baked and production ready processor like Saxon-B or better yet Saxon-SA. Don't get me wrong... I stand full whole heartedly behind ANY company, entity, or individual willing to the put the necessary resources into building a XSLT 2.0 compliant processor. But it scares me to see statements like:

"In addition to support for XSLT 1.0, Altova *XMLSpy. 2005* includes --> the industrys first production-grade implementation <-- of the important new XSLT 2.0 and XPath 2.0 specifications, which are both used in XSLT development..."

We obviously no that this is an flat out lie (sorry Altova, Dr. Kay beat you to the punch about 8 months ago from a complete spec standpoint and by years from the standpoint of partial support for what would become portions of the XSLT 2.0 spec) and a rediculous statement to make in November of 2004 even if there was a 100% fully compliant XSLT 2.0 processor... which DOES NOT EXIST!!!

I'm sorry, but I am just flat out dissappointed that a company with as much market share as Altova has with XML Spy would make contradictory statements within a few clicks of each other on there own site. But to add to this the claim they were the first to produce a production grade implementation when anybody with even half there senses intact knows that Saxon has been the bar at which EVERYTHING else has been measured against for both compliance to the spec as well as the ability to run production code with the same reliability and consistency that Dr. Kay has built into Saxon.. And that is for both 1.0 AND 2.0 .... hmmmmm... very disappointing Altova....


It's a good question, and I think it's still quite early days to tell, because Saxon is certainly not using the schema information to anything like its full potential at this stage.

The biggest advantage I have found so far comes from result document
validation: if your stylesheet generates invalid output, you get diagnostics
that point you straight at the line number containing the error. A simple
thing, but I think it can greatly speed up the process of developing a
stylesheet that produces correct output.


Coming back to the real world of XSLT 2.0 compliant processors -- Dr. Kay, one of the "missing" portions of one of the projects I have worked on over the last 8 months (AspectXML.org) is the ability to use Schema to validate the input, the mapping, and then the output of the XSLT 1.0-based Aspect weaving engine. One of the things I see as great potential with Saxon-SA (or any other XSLT 2.0 Schema-Aware compliant processor that may become available in the future) is to introduce at the Aspect Oriented Software Development level the ability to validate every line of code that may be introduced via cross cutting concerns and to ensure that choices can be made at run time what to do when the code does'nt validate (e.g. stop the process, clean up the code to conform to the standards set forth and continue, ignore it all together, etc...) against a given schema, be it a static Schema that exists on the file system or a dynamically woven schema that is then used to further validate dynamically woven aspects. With IBM putting as much time and money into the development of tools for AOSD as well as an every increasing allocation of shelf space at Barnes & Noble and Borders & there UK-based counterparts for AOSD related titles (my good friend Russ Miles - who was the original creator of the idea for AspectXML of which we then joined forces to build - just finished the AspectJ Cookbook - An Oreilly Cookbook to me says a lot about where OReilly feels a particular technology is already or is heading towards...) I have this sense that utilizing the advanced features available in Saxon-SA coupled with Schema and AspectXML could truly revolutionize the way software is built, validated for conformance to particular standards, archived and indexed for use at a later date within other projects.. and the list goes on and on.

My question to you from the above statement then is what is your take on using a processor like Saxon-SA to utilize a process involving a combination of XML, XSLT, and Schema files to act as a pre-processor to the compilation of a software project, be it an AOSD-based project or even a standard OOP-based project?

To me I see MASSIVE gains that can come from this type of system - From a 1 man development team to a 250 man corporate development project (even more so at this level when you consider the amount of code that is usually just left sitting on someones harddrive completely unkown and/or unnoticed and as such reducing a companies assetts to a fraction of there potential if this code were to be located, accessed, analyzed, processed, validated, serialized as XML, and returned as an assett that is now completely indexed and available for use). I realize that a lot of this can be seen as Pipe Dream material and some may argue that these types of tools already exist in other formats. While I won't argue against this I will suggest that there is plenty of room for improvement... Could a Schema-Aware processor like Saxon-SA be a key factor in revolutionizing the way we build software - Structured XML and Semi-structured text alike?

Thanks for any and all insite you are willing to give on this matter!

Best regards and thanks again for giving us Saxon!

<M:D/>

Michael Kay

Current Thread