[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: killing xslt

Subject: RE: killing xslt
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Tue, 18 May 2004 07:55:16 -0600
aspectxml
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.
> ------------------------------------------------------------------

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.