[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] killing xslt


Subject: RE: [xsl] killing xslt
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Tue, 18 May 2004 08:10:49 -0600

http://www.aspectXML.org/aoxml/downloads/aspectXML_advanced_xslt_weave.z
ip

just in case your file got cut off like it did in the email I got back
containing my response here's the link again, but corrected to get you
access to the correct file.

> -----Original Message-----
> From: M. David Peterson [mailto:m.david@xxxxxxxxxx]
> Sent: Tuesday, May 18, 2004 7:55 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] 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: [xsl] 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
> > > 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