RE: killing xslt
Hi Jirka, In that Michael Kay took the time to give you his advice I would definitely take heed to his comments. However, if you decide to continue with this topic or a variation of it (again, Dr. Kay is by far the best person you could ever hope to get advice from in this area so I would definitely pay attention to what he has to say) then I would contact Pieter Siegers and ask that he include you on the projects internal mailing list. If I might add a bit of my own advice to you regarding this... I too agree that option 3 sounds the most promising for several reasons. - Just like Dr. Kay emphasized the data types are exact and therefore will not require conversion which I can promise you will be the biggest issue you face if you attempt to merge two technologies whose data types are not directly compatible (think of all that has gone into the CLR on .NET and it will probably make a lot more sense how important this is) - Once you have created a solution that properly converts a certain type of solution in XSLT 2.0 into the XQuery equivalent you can then utilize this solution over and over again much like you would a template in XSLT 2.0 - The solution would be built on top of technologies that have already won over the support of powerhouses like Microsoft (ok, we don't need to get started on this at the moment so Ill keep my comments to myself ;) - The syntax used in XQuery is more familiar to a lot of developers which means they are more likely to implement and extend a solution that builds upon there knowledge base - The solution would allow developers familiar and comfortable with the XSLT syntax to continue development using something they are more comfortable with while maintaining compatibility with projects that do not implement an XSLT 2.0 processor. - And once your library of solutions was created you could utilize the power of preexisting projects that are designed to weave an instance of one thing into a format defined in another XML file. And it just so happens I know of such a project :) (ok, yes, I developed the XML/XSLT code base for the base of this project, but it works and that's what count, right? :) AspectXML was the brainchild of a very good friend of mine and he and I have since been developing the idea piece by piece when we have some extra time here and there to do so. The idea of the project is to weave together instances of an applications aspects using Aspect-Oriented Software Development techniques but to do it using XML to define the aspects and how they should be woven and use XSLT to do the weaving. Although I haven't had a ton of time lately to make updates to the code base that are necessary to make it more robust the advanced version of the XSLT base will do for you EXACTLY what it is you are trying to do... or in other words, parse an input file and transform the elements you find into there XQuery equivalent code base and output that so that this XQuery base can then be used to perform the same function as the original stylesheet intended. At the moment you actually need to make anonymous access to the CVS server for the AspectXML.org domain to gain access to the XSLT files I am referring to... But I am in process of zipping them up and posting them to the main download area by themselves so that you can download them and play around with them a bit to get a feel for what I am referring to. In quick summary the instance file is transformed by the XSLT file (only one in the zip file) which uses the AspectDefininition.xml file as a way to tag and reorganize each instance found in the instance file to then be compared against a third file which "weaves" the data according to the "definition" found in this file. A simpler way to think of it is like so: Aspect instances A=1 B=2 C=3 Aspect definitions 1=Monday 2=Tuesday 3=Wednesday Output definitions Monday=Sloppy Joes Tuesday=Spaghetti Wednesday=Hot Dogs Although this is a very basic example it works to show that if we combine the aspect instances of the first example with the definitions of the second example we can then use the third example to show that A=Sloppy Joes B=Spaghetti and C=Hot Dogs. Again, although very basic, using these same concepts we could use an output definition that was much more complex and contained many more elements to represent an XQuery algorithm that is the equivalent of an XSLT 2.0 algorithm. By using the middle file to separate the things of importance such as variables and items that contain type information, elements that are in a certain format (e.g. <xsl:template match="/">) and all the other parts that make up and XSLT file and then put them in a format that is non technology specific (e.g <xsl:template match="/"> may convert to just <template match="/">) we allow the XSLT file to use the third file to make simple matches and as such easily reassemble the results in a format that meets the requirements of the algorithm developed earlier in the development stage of the project. Although the development of the algorithms will be quite difficult, once they are developed it will be cake walk actually transforming a new XSLT 2.0 doc into XQuery format. By simply stating what you want the output to look like and where each part of the output finds the information it needs to build itself correctly you can now perform extremely complex transformations and weavings of languages that in theory are extremely difficult but in practice have become childs play. Take a look at the following site: http://www.AspectXML.org and download this zip file http://www.aspectXML.org/aoxml/downloads/aspectXML_advanced_xslt_weave.z ip (you wont find the link on the site as my buddy Russ Miles (the brainstormer of the AspectXML idea) is still in the process of implementing the java side of this which will allow much more complex weavings of XML which will convert to Java code at run time as needed and then deleted just as soon as the woven object is no longer needed. As such, the only way to access these on the site is through CVS - these instructions for anonymous access are on the site). Keep in mind that the terminology uses in these files may not seem familiar but by simply creating versions of the files that meet the syntax you are looking for you can immediately overcome that obstacle. The XSLT has been designed in such a way that it doesn't care what the element and attribute names are beyond the simple containing parent names of each file such as "output", "definition" "aspects", "aspect", and "root". In other words the elements that contain the contents of each file are standard but beyond that it is up to you to determine. Well, I realize ive dumped a lot of stuff on you but if you are working on developing the thesis for your PhD I think youre probably smart enough to figure things out. None the less, if this is something you find helpful and have any questions I would be more than happy to help you get things figured out. Hope this is helpful! Best regards, <M:D/> > -----Original Message----- > From: Jirka Kosek [mailto:jirka@xxxxxxxx] > Sent: Tuesday, May 18, 2004 2:00 AM > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: killing xslt > > M. David Peterson wrote: > > > I should also point out that Dave Pawson offered to post a "call for > > effort" on his highly visited/read xsl-faq which would be a tremendous > > way to rally further support especially as the project gets into the > > fine tuning and massaging of the code base to take advantage of the .NET > > platform and the differences it has between the Java platform. As you > > said it would be lovely to get absolute precision from the Beta of > > version 3 of the Java to C#/.NET conversion tool but highly unlikely and > > therefore this will require the artisan style craftsmanship of several > > developers if we want to get a release out to the public within a timely > > manner. > > I'm just formulating theme for my PhD thesis. Finally I decided that > "Implementing XSLT 2.0 in .NET" will be an interesting one. As am I > thinking about this topic, there are several ways to go: > > 1. Automatically translate Java code of Saxon to C# (this is the way you > propose) > > 2. On-the-fly translation of XSLT 2.0 stylesheet into XSLT 1.0 + EXSLT + > scripts > > 3. Write own XSLT 2.0 engine on the top of XQuery/XPath engine in .NET > Framework 2.0 > > 4. Write whole XSLT 2.0 engine from scratch > - as interpreter > - as preprocesor which generates C# code > - as direct MSIL code (.NET byte-code) generator > > I plan to explore all possibilities and of course we can share > experience from 1st approach. > > It is hard to predict something before detailed analysis, but I think > that finally I will use 2nd or 3rd approach as it allows reuse of very > fast XLST (or at least XPath) engine in .NET and allows smooth > integration with rest of System.Xml -- using XmlDocument or > XPathDocument as source tree representation, modelling XSLT API after > System.Xml.Xsl. > > Jirka > > -- > ------------------------------------------------------------------ > Jirka Kosek e-mail: jirka@xxxxxxxx http://www.kosek.cz > ------------------------------------------------------------------ > Profesionalnm 9kolenm a poradenstvm v oblasti technologim XML. > DocBook 18.-19.5. XSLT 24.-26.5. > XML pro v}vojaxe 7.-8.6. XSL-FO 16.6. > ------------------------------------------------------------------
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format