A new TSS article, by Joseph Chandler, presents an architecture to solve the problems presented by XSL needing to be well formed XML when working with Entity references, import and include mechanisms. By processing the XSL as a JSP page, the developer can use JSP include tags, producing a well-formed XSL file that can be compiled into a Template class, which is useable by an XSLT processor.
Read
Skin Emax - An XML/XSLT Architecture for the Web
-
Skin Emax - An XML / XSLT Architecture for the Web (43 messages)
- Posted by: Nate Borg
- Posted on: April 28 2003 19:44 EDT
Threaded Messages (43)
- Skin Emax - An XML / XSLT Architecture for the Web by Drew McAuliffe on April 28 2003 21:06 EDT
- XML/XSL does have its place by Don Brown on April 28 2003 22:36 EDT
-
XML/XSL does have its place by Drew McAuliffe on April 29 2003 12:24 EDT
-
dynamic data transformations by Rolf Tollerud on April 29 2003 03:49 EDT
- dynamic data transformations by Reinhard - on April 29 2003 05:12 EDT
-
dynamic data transformations by Dave Hewitt on April 29 2003 05:44 EDT
-
dynamic data transformations by Erik Bengtson on April 29 2003 06:01 EDT
- dynamic data transformations by Rolf Tollerud on April 29 2003 06:44 EDT
-
sqldts is very fast and scalable by Rolf Tollerud on April 29 2003 06:37 EDT
- sqldts is very fast and scalable by Dave Hewitt on April 29 2003 10:47 EDT
-
Babeldoc by Dejan Krsmanovic on April 29 2003 08:19 EDT
-
Babeldoc by Drew McAuliffe on April 29 2003 11:11 EDT
-
at last a real answer.. by Rolf Tollerud on April 30 2003 12:43 EDT
- at last a real answer.. by Drew McAuliffe on April 30 2003 01:54 EDT
-
Babeldoc by Dejan Krsmanovic on April 30 2003 04:30 EDT
- Babeldoc by bruce mcdonald on April 30 2003 09:34 EDT
-
Babeldoc by Brian Miller on April 30 2003 05:11 EDT
-
Babeldoc by bruce mcdonald on May 01 2003 09:52 EDT
-
XSL kicks ass!, Babeldoc by Brian Miller on May 01 2003 12:14 EDT
-
XSL is not the only tool in the toolchest. by bruce mcdonald on May 01 2003 10:39 EDT
- XSL is not the only tool in the toolchest. by Brian Miller on May 02 2003 12:32 EDT
- XSL kicks ass!, Babeldoc by Erik Klein on May 16 2003 02:04 EDT
-
XSL is not the only tool in the toolchest. by bruce mcdonald on May 01 2003 10:39 EDT
-
XSL kicks ass!, Babeldoc by Brian Miller on May 01 2003 12:14 EDT
-
Babeldoc by bruce mcdonald on May 01 2003 09:52 EDT
-
at last a real answer.. by Rolf Tollerud on April 30 2003 12:43 EDT
-
Babeldoc by Drew McAuliffe on April 29 2003 11:11 EDT
-
dynamic data transformations by Drew McAuliffe on April 29 2003 12:21 EDT
-
dynamic data transformations by bruce mcdonald on April 30 2003 10:22 EDT
- dynamic data transformations by Drew McAuliffe on April 30 2003 01:56 EDT
-
dynamic data transformations by bruce mcdonald on April 30 2003 10:22 EDT
-
dynamic data transformations by Erik Bengtson on April 29 2003 06:01 EDT
- dynamic data transformations by Drew McAuliffe on April 29 2003 12:17 EDT
- JSP as a transformation alternative. by Marko Milicevic on April 29 2003 03:50 EDT
-
dynamic data transformations by Rolf Tollerud on April 29 2003 03:49 EDT
-
XML/XSL does have its place by Race Condition on April 29 2003 02:25 EDT
-
Transformation pipelining by Don Brown on April 29 2003 02:59 EDT
-
Transformation pipelining by Drew McAuliffe on April 29 2003 05:09 EDT
-
Cocoon2 is a totally different animal by Don Brown on April 29 2003 06:33 EDT
-
Cocoon2 is a totally different animal by Drew McAuliffe on April 29 2003 06:58 EDT
- the Skin framework could use Cocoon's XSLT processor by george li on May 04 2003 04:57 EDT
-
Cocoon2 is a totally different animal by Drew McAuliffe on April 29 2003 06:58 EDT
-
Cocoon2 is a totally different animal by Don Brown on April 29 2003 06:33 EDT
-
Transformation pipelining by Drew McAuliffe on April 29 2003 05:09 EDT
-
Transformation pipelining by Don Brown on April 29 2003 02:59 EDT
-
XML/XSL does have its place by Drew McAuliffe on April 29 2003 12:24 EDT
- Benefits without the XML speed problems by Gene Kuznetsov on April 29 2003 17:53 EDT
-
Benefits without the XML speed problems by Drew McAuliffe on April 29 2003 11:16 EDT
- Scripting vs. XML vs. XSLT by Gene Kuznetsov on May 01 2003 09:15 EDT
-
Benefits without the XML speed problems by Drew McAuliffe on April 29 2003 11:16 EDT
- XML/XSL does have its place by Don Brown on April 28 2003 22:36 EDT
- Cocoon 2 by Reinhard - on April 29 2003 03:38 EDT
- Re: XSL as a JSP page by Marina Prikaschikova on April 29 2003 05:36 EDT
- grid XSLT by Cameron Purdy on May 01 2003 14:01 EDT
- OXF by Erik Bruchez on May 01 2003 19:29 EDT
- Is it possible to get the source distribution of skin framework? by george li on May 04 2003 04:51 EDT
- JavaOne Session on XML and JSP by Erik Bruchez on May 08 2003 18:30 EDT
- Source Distribution by Tom Marrs on May 14 2003 13:41 EDT
-
Skin Emax - An XML / XSLT Architecture for the Web[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 28 2003 21:06 EDT
- in response to Nate Borg
Are people still pushing XML/XSL as a viable web framework? It has been my (painful) experience that XSL is not a workable, maintainable solution.
1) XSL is a poor language with limited expressiveness. It has one of the most awkward, counterintuitive syntaxes I have ever encountered.
2) It is SLOW SLOW SLOW. I have seen many performance reports that indicate this and my saw first-hand an XSL-based architecture at my last fulltime job that was just a performance nightmare. Not only do you have to deal with the problems of XML serialization, but XSL processors just run a lot slower than other methods of putting together a web page.
What's the general consensus out there? Don't think of this as flamebait but rather as a request for proof to the contrary. -
XML/XSL does have its place[ Go to top ]
- Posted by: Don Brown
- Posted on: April 28 2003 22:36 EDT
- in response to Drew McAuliffe
I agree - XSL can be difficult to work with and it certainly is slow, although there are techniques to mitigate that somewhat. However, there are several distinct advantages to such a framework:
1) Strong separation enforced between data and presentation. The awkwardness of XSL is partly to thank. :)
2) Ease of which templates can be included, imported, and transformations pipelined.
3) Great flexibility when integrating with other systems - human or automated. The XML data can be combined with any stylesheet creating HTML, XML, WML, CSV, or any other text-based format. In addition, the XML can be returned as is for loosely coupled integration with other systems (ie. a portlet in a web portal or a poor man's web service).
4) XSLT skills are cross-platform (used in Java, .NET, Perl, C++, etc).
5) Client side transformations will reduce bandwidth usage and improve server performance
Number 3 was the deciding factor on my last project. One of the big issues in the Navy is they have thousands of stovepipe web applications and want to find ways to leverage the functionality in new applications such as their web portal. A web application written using XML/XSL can easily return XML for processing by the new client saving the Navy the thousands of dollars that may be required to rewrite parts of the application.
The awkwardness of XSL can be mitigated by pipelining the transformations (ala Cocoon) to keep the transformations small or eliminate them altogether. In fact, XML processing application could use JSP or Velocity to create the content and be processed by STX or SAX content handlers.
Again, an XML-based solution, which can include XSL but doesn't have to, will probably be slower than presentation technologies, but what you lose in performance, I feel you more than make up in flexibility and maintainability. Of course those tradeoffs can't be made in many cases, but when they can, it might be worth it.
Don -
XML/XSL does have its place[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 00:24 EDT
- in response to Don Brown
I would agree that when integration is a key concern, XML has a lot of advantages. I've done a great deal of integration work and have used XML heavily in it. I actually got bitten in the ass by XSL, though. We were putting together a system for a telecom provider that would provide one common way to integrate telecom orders regardless of carrier. We had our internal representation of the order and would send it through several transformation layers to go out the other side as an order in whatever format the carrier required: xml, excel file, even pdf forms that would need to be faxed. I sort of forcefed the idea of XSL as the basis for our transformation system because I thought that a) it was the hot new thing (back in 1999/2000) and b) all sorts of great tools would be coming out to make it easier. Well, the tools never quite came out the way we'd expected and for complex data transformations, XSL just didn't cut it. It's fine for rearranging data for display but for handling complex, rule-based transformations from one object graph to another, it wasn't sufficient. I got bit in the ass because I was forced to try to handle the complex mappings using the limited XSL tools that were available. After that experience, I really wished we'd gone down the route of some other transformation mechanism. Unfortunately, there's nothing I've seen then or now that really fits the bill. Webmethods had something that came pretty close but it was proprietary and required their (expensive) product. The problem with XSL is that it doesn't handle normal kinds of computation that you can do in any other language, or at least if it does, it doesn't handle it well. You end up with a bizaare mixture of javascript, xsl, and xml that is a nightmare to maintain when you're dealing with hundreds of complex mappings.
So for limited integration work, XSL might work fine. For anything more complicated than that, it just doesn't cut it. Though in an integration scenario, I think you do need some sort of XML-based architecture no matter what your transformation mechanism is. Other scenarios that XML might work well for: publishing or content-based sites with distributed authorship, web service friendly stuff, where your focus is on delivering web services(otherwise, web services are better done as an adjunct to your core system and shouldn't dictate the underlying architecture), and I guess maybe something where you want to have DHTML tree-based navigation and xml data structures help (though this last case is what people in my old company tried to do that I mentioned in my original post).
With that in mind, as a side note to this, does anyone have any alternatives to XSL that would be good for doing dynamic data transformations? I've always wanted something (preferably open source) that could do that. I'm talking complex transformations where your managing the mapping between lots of nodes (up into the hundreds), and where you have a system where keeping track of your transformations and keeping them up to date is important (so ease of mapping and transformation management is key). -
dynamic data transformations[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: April 29 2003 03:49 EDT
- in response to Drew McAuliffe
Drew,
For just rearranging data for display in web-applications, CSS2 is sufficient and very easy to use, by a power of degree easier to use than XSLT. This has been kind of overlooked and is not very well known.
http://www.zvon.org/xxl/CSS2Reference/Output/index.html
Take a look on selectors (https://www.w3.org/TR/REC-CSS2/selector.html), pseudo-classes and display: table, display: table-row, display: table-cell.
For complicated data transformation in the MS world, you have the Data Transformation Services (DTS) in SQL Server:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/dts_overview.asp
What I would like to know is - if there is any equivalent (Open Source or commercial) product to for Java?
Regards
Rolf Tollerud -
dynamic data transformations[ Go to top ]
- Posted by: Reinhard -
- Posted on: April 29 2003 05:12 EDT
- in response to Rolf Tollerud
If a GUI is NOT a must for you check out Cocoon (completly written in Java) - especially the Cocoon control flow which is included in Cocoon 2.1M1 which will be available during the next days. (http://cocoon.apache.org)
Reinhard -
dynamic data transformations[ Go to top ]
- Posted by: Dave Hewitt
- Posted on: April 29 2003 05:44 EDT
- in response to Rolf Tollerud
This is one good data processing / pipelining tool
http://sourceforge.net/projects/babeldoc/
As a long-time DTS user myself, I have to say you would struggle to do with DTS what you can do with transformation pipelines - it is simply too limiting. For example, using SQLServer, how would you, say, render a JPEG from a set of coordinates and ftp it to a remote server? Using XSL, this is not only trivial, but I can change it at runtime, without compiling any java code at all.
DTS is fast, and pretty good at what it does, but its certainly not a flexible, extensible transformation architecture.
I have to say, personally though, I do not like using XML/XSL for rendering a display - I use it primarily for data transformation pipelines and syndication. Not to say I think its wrong, its just not what I use it for. -
dynamic data transformations[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: April 29 2003 06:01 EDT
- in response to Dave Hewitt
> DTS is fast, and pretty good at what it does, but its certainly not a flexible, extensible transformation architecture.
>
Thats right. I have used that a long time, and you need to create a lot of VBscript / components because its just usefull for simple transformation mappings -
dynamic data transformations[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: April 29 2003 06:44 EDT
- in response to Erik Bengtson
"I had to use scripting for transformation mappings"
Any "non-trivial data transformation" have to include custom code, that is self-evident, what else? -
sqldts is very fast and scalable[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: April 29 2003 06:37 EDT
- in response to Dave Hewitt
it is simply too limiting
How can it be too limiting when you anytime can extend the package with for example XSLT transformations and/or custom-made code?
For example, using SQLServer, how would you, say, render a JPEG from a set of coordinates and ftp it to a remote server? Using XSL, this is not only trivial, but I can change it at runtime, without compiling any java code at all
I do not understand what you mean with "render a JPEG from a set of coordinates". Ftp a JPEG to a remote server is trivial with "FTP task".
About Babeldoc.
How can you compare a little know product like Babeldoc, with very little activity and low "Usage Statistics", maintained by 4 developers with no online Javadoc for its API and with all in all 45 post together in "help" and "Open Discussion" forums - with a mainstream product like MS SQLDTS, used by ten of thousands of developers and backed by the full force of MS and the SQL Server team?
A sense of proportions is needed.
Regards
Rolf Tollerud -
sqldts is very fast and scalable[ Go to top ]
- Posted by: Dave Hewitt
- Posted on: April 29 2003 10:47 EDT
- in response to Rolf Tollerud
Rolf, I was not wishing to hold Babeldoc up as an equivalent to SQL
Server DTS (although rereading your original post, that's what you were
asking for it seems), merely an example of the kind of data
processing/transformation pipelining tool that can be freely obtained on
the open source world (there are others, this is just my current
favourite). I'm also not saying I've switched from DTS to Babeldoc for
everything, and the rest of the world should follow suit. I use
pipelining like this when appopriate, on projects that suit it, and it
is nice to have a flexible, free option available when necessary.
> How can you compare a little know product like Babeldoc,
> ... with a mainstream product like MS SQLDTS,
> used by ten of thousands of developers and backed
> by the full force of MS and the SQL Server team?
Well I didn't originally intend to (I think the two are very different
and I have used both in tandem before), but you haven't offered a
particularily compelling argument there - it's kind of like saying, how
can I prefer my home-grown organic vegetables, that nobody else has ever
eaten, to having a nice Macdonalds that millions of people enjoy
everyday. Its an argument based on twisted logic that proves nothing.
Fine argue on technical merit, point out shortcomings (I'm well aware they exist), stress the different focus of the tools. But usage statistics
and market penetration? Sounds like a sales pitch to me. And asking for
an example of an open source processing pipeline, and then rubbishing it
for not having as much muscle behind it as a microsoft product is a poor
show indeed.
I could care less about the thousands of developers using DTS and the
development clout behind it if it doesn't do what I want - which quite
frequently it doesn't. In those instances I will gladly set aside my
hammer, and pick up a screwdriver instead. Different tools, with a
different focus and different capabilities.
Irrespective of the usage statistics, profile and homepage quality,
Babeldoc is very nice to use, under active development and comes with a
hell of a lot of very useful features out of the box (unlike many, more
active sourceforge projects). Yes, of course a free tool will look
shabby compared to the clout of an MS developed tool and its fancy
designer - these guys are developing stuff that interest them, they're
not interested in a DTS competition. But their tool suits a lot of what
I do, and therefore I use it, recommend it and applaud their efforts
(and if I get a chance, maybe I'll contribute).
And do you know what? There's situations where Babeldoc just doesn't cut
it - and so I use something else instead (maybe DTS if the job's right).
I am fortunate in that I have the freedom to be able to do that, rather
than continuing to bash screws into the woodwork with my DTS-shaped
hammer.
By the way, what I meant by rendering a JPEG was something like - take an XML format
document or SQL query, transform that into, say, a set of graph coordinates,
transform that into an SVG, rasterize it as a JPEG, ftp (or JMS) it to
your frontend server. All defined in plain, easy to understand, easy to modify XML.
DTS is a tool just like any other, and one which I am happy to use as
long as it fits the job - which is not always the case. Perhaps you can
get by with having to find kludgy workarounds for problems like being limited
to one datarow in / one datarow out when doing a datapump, or being
forced to use a named MAPI profile for sendmail. Perhaps everything you
do is a good fit for DTS, in which case fair play to you. When it comes to the point where almost all of my functionality is provided entirely by custom scripts, I have to ask myself what exactly I am buying by
continuing to use a tool.
Personally, I like the fact that, since Babeldoc's process flow is
defined in XML (unlike DTS's binary... thing) I can generate different
process flows, from scratch, on the fly, using XSL. Who cares if its
missing a visual designer if you've got elegance like that? Besides,
DTS's visual designer is pretty limited (and phenomenally slow) for most non-trivial tasks
anyway - you end up pratting around in the code, trying to get it to do what
you want. -
Babeldoc[ Go to top ]
- Posted by: Dejan Krsmanovic
- Posted on: April 29 2003 20:19 EDT
- in response to Rolf Tollerud
Rolf,
Babeldoc does have online Javadoc documentation. Check out http://www.babeldoc.com/development/build/javadoc
I know Babeldoc is not in top 10 projects on SurceForge but we do have mailing list far more active then our forums on Source Forge. Keep in mind that Babeldoc is still in beta (1.0 version will be released in May) and that project has started less then one year ago.
But we do have more and more users every day and many of them are contributors, too. That is beauty of Open Source - if you want some feature that is not implemented yet, you are free to implement it! Don't need to wait Microsoft to do it! Of course we cannot compare to comercial produts but Babeldoc solves problems and it is free.
Dejan Krsmanovic
Babeldoc user and developer -
Babeldoc[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 23:11 EDT
- in response to Dejan Krsmanovic
How would you compare Babeldoc to the recent updates to Cocoon? At someone else's suggestion, I checked out Cocoon2 and it seems to be focusing more on generic pipelining and data transformations than xml serialization with xsl translation. I haven't read your whitepapers yet (I don't have openoffice installed; pdf versions would be great!) to get a full understanding of your overall design but it appears (at cursory glance) to share some architectural concepts with Cocoon2. What are some of your differentiating features?
I guess I should explain why I'm so interested in this. I worked in EAI for several years and never found anything 100% satisfactory, or even 80% satisfactory with room for extension. I'd long thought about writing my own transformation mechanism but never had the time. I really think that a well-designed, easy to manage, OPEN (Rolf!) and extensible transformation mechanism is one of the most powerful tools an enterprise can have. Combine that with a good asynchronous bus (recent postings on TSS make me interested in Sonic) and you've got a tremendously powerful and flexible mechanism for doing really effective systems integration. The great thing is that something like this could offer a solution comparable to what people like WebMethods, Tibco, and Vitria have been charging an arm and a leg for. As long as the bus was fast and reliable, and you had control over the transformation points, you could turn just about anything into anything else and link things up pretty nicely. -
at last a real answer..[ Go to top ]
- Posted by: Rolf Tollerud
- Posted on: April 30 2003 00:43 EDT
- in response to Drew McAuliffe
I worked in EAI for several years and never found anything 100% satisfactory, or even 80% satisfactory with room for extension. I'd long thought about writing my own transformation mechanism but never had the time
thank you..
Regards,
Rolf Tollerud -
at last a real answer..[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 30 2003 01:54 EDT
- in response to Rolf Tollerud
You're welcome? Your point? -
Babeldoc[ Go to top ]
- Posted by: Dejan Krsmanovic
- Posted on: April 30 2003 04:30 EDT
- in response to Drew McAuliffe
I think Babeldoc and Cocoon has some similiar architecture concepts altough these products serves different purposes.
I really haven't worked a lot with Cocoon but as I could see it is primarly used for generating sitemaps and is mostly request/response oriented. Sorry if I am wrong!
On the other hand Babeldoc is more document oriened. There are many ways for feeding pipelines - using stand alone applications, scanners, SOAP... Scanners can be used for scanning file systems, ftp servers, mail servers ...
XSL transformation is just one feature (pipeline stage) that you may use or not. In fact documents don't need to be xml at all. You can process both binary and ascii documents. There are cases where you just want to automate some process (example: getting an attachment from e-mail and sending it to few addresses or uploading to FTP server, or just inserting record in db) where you don't need XSL at all. But in most other cases you will end up using it at one way or another.
Also Babeldoc has Jornal mechanism so you can always know what stages has been finished successfully and which has failed. You can store whole document at one stage in Journal so in case of failures you can re-introduce document from last successfull pipeline stage. For example if you use stage for uploading document to ftp server, you can store document into Jornal at some stage before. So if ftp server is down for a while this stage will fail and processing could be stopped. But later when ftp server is up again you can "replay" processing from last successfull stage with stored document.
There are many cases where you can use Babeldoc. A lot of users have contributed by writing their own pipeline stages implementing features that wasn't planned at all in the begging. I have started as user (probably the first one!) but pretty soon I needed some features that wasn't there and started to write them. Pretty similiar things happens with other users. So keep in mind that you won't find everything you need in Babeldoc but you can always extend it.
Dejan -
Babeldoc[ Go to top ]
- Posted by: bruce mcdonald
- Posted on: April 30 2003 09:34 EDT
- in response to Dejan Krsmanovic
Babeldoc is a pipelined transformation engine. It is configurable through property files or SQL tables. Here are the following aspects to the project:
1. Used by a number of very large financial / banking corporations.
2. Java, open source project
3. flexible and reconfigurable
4. Document based pipeline transformation engine
5. Primarily, but not limited to, XML based operations.
6. Active developer community.
At the moment we are finishing up version 1.0. After this is done, we can start addressing the following aspects:
1. J2EE integration (already mostly done)
2. GUI builder and management tools.
regards,
Bruce McDonald.
2. -
Babeldoc[ Go to top ]
- Posted by: Brian Miller
- Posted on: April 30 2003 17:11 EDT
- in response to Dejan Krsmanovic
<quote>
I think Babeldoc and Cocoon has some similiar architecture concepts altough these products serves different purposes.
</quote>
As far as I know, Cocoon is the only transformation tool (pipelined or not) that allows blocks of Java statements within an XSL stylesheet. That's significant. -
Babeldoc[ Go to top ]
- Posted by: bruce mcdonald
- Posted on: May 01 2003 09:52 EDT
- in response to Brian Miller
Embedding Java code inside of XSL is not a particulary good idea. It is not a good to do it in JSP for the same reasons. What babeldoc does provide is a complete scripting environment within XSL. From within the XSL you are able to execute Velocity scripts which permeate the length and breadth of babeldoc. Additionally you can embed javascript and jython in the xsl - I can personally attest to the fantastic performance of javascript (rhino) and the elegance of its implementation. A number of users are doing some extremely interesting things with rhino and babeldoc including j2ee integration. -
XSL kicks ass!, Babeldoc[ Go to top ]
- Posted by: Brian Miller
- Posted on: May 01 2003 12:14 EDT
- in response to bruce mcdonald
<quote>
Embedding Java code inside of XSL is not a particulary good idea. It is not a good to do it in JSP for the same reasons. What babeldoc does provide is a complete scripting environment within XSL. From within the XSL you are able to execute Velocity scripts which permeate the length and breadth of babeldoc. Additionally you can embed javascript and jython in the xsl - I can personally attest to the fantastic performance of javascript (rhino) and the elegance of its implementation. A number of users are doing some extremely interesting things with rhino and babeldoc including j2ee integration.
</quote>
How strange that Google found no hits for "xsl javascript babledoc" globally and no hits for "xsl javascript site:babledoc.com". Are you sure with babledoc that "you can embed javascript and jython in the xsl", as you said? Babledoc's whitepaper makes no mention of this. The W3C's XSLT specification has no description of non-XSL scripting within an <xsl:template>'s body. It's left for the vendors to define. Babledoc's literature still leaves me guessing if it's even supported. All I can find mention of is a seperate JavaScript stage in babledoc's transformation pipeline. That's a far cry from nesting JavaScript within an <xsl:template>.
Anyway, why are you praising interpreted JavaScript and slighting dynamicly-recompiled strongly-typed class-based Java as offered by JSP and Cocoon?
And I don't consider Velocity to be as technologicly advanced as JSP or Cocoon's XSP. Perhaps Velocity's greatest fault is its failure to use XML for its template language. Just my opinion. -
XSL is not the only tool in the toolchest.[ Go to top ]
- Posted by: bruce mcdonald
- Posted on: May 01 2003 22:39 EDT
- in response to Brian Miller
Well, take from me that you can (I wrote the initial implementation of Babeldoc). We use Xalan and Xalan can embed Javascript (using BSF) and other compliant script languages. As for the google searches, that will be remedied. Just because you can't find it, does not mean that it does not exist.
And you are correct that Velocity is not as technologically advanced as JSP or XSP, it doesn't have to be. It is clean, simple runs fast and that in my book, is worth a lot. I have seen my fill of ugly as sin jsp and xml and you can keep it. "Technologically advanced" can be a trap for the naive.
As for praising interpreted JavaScript its like a swiss army knife - it is hideously expressive (too much so perhaps), very fast and is understandable by a large group of people. It allows for lots of interesting things to be done without having to crack open a java development environment. I use Javascript to iterate over the pipelines, generating XML documentation which then gets XSLed into DOCBOOK which is then XSLed into html. All without having to write a single line of Java and all from within babeldoc. Another babeldoc user is using Jython to connect to a Weblogic EJB webcontainer and submit documents. Again all without a line of java being written.
XSL is great. Its just that its not the only tool in the chest. And that is the babeldoc philosophy. -
XSL is not the only tool in the toolchest.[ Go to top ]
- Posted by: Brian Miller
- Posted on: May 02 2003 00:32 EDT
- in response to bruce mcdonald
<quote>
Well, take from me that you can (I wrote the initial implementation of Babeldoc). We use Xalan and Xalan can embed Javascript (using BSF) and other compliant script languages.
</quote>
As far as I know Xalan only allows non-XSL script to be inlined within a <xalan:script> top-level element, but not directly within an <xsl:template>. Cocoon allows both. You might consider it a nitpick, but many real-world transformations surely could benefit by inlining an industrial programing language directly within the XSLT logic. I appreciate the symmetry of being able to embed Java anywhere within XSLT and vice versa. See for example some XSL tags within a Java block within an <xsl:template> at,
http://xml.apache.org/cocoon/userdocs/xsp/logicsheet-concepts.html#helper-classes -
XSL kicks ass!, Babeldoc[ Go to top ]
- Posted by: Erik Klein
- Posted on: May 16 2003 14:04 EDT
- in response to Brian Miller
<How strange that Google found no hits for "xsl javascript babledoc" globally and no hits for "xsl javascript site:babledoc.com".
>>
The correct spelling is "babeldoc", not "babledoc". Try your google search again. -
dynamic data transformations[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 12:21 EDT
- in response to Dave Hewitt
THanks for the link. That's kind of what I was looking for. I like how the author said "Not a replacement for webmethods (yet)", because webmethods is probably the best example of this sort of thing that I've seen thus far. It's just too expensive and locked into the webMethods server (I can't easily get a webmethods transformation running from a simple socket/console app, for example). -
dynamic data transformations[ Go to top ]
- Posted by: bruce mcdonald
- Posted on: April 30 2003 10:22 EDT
- in response to Drew McAuliffe
Its not a replacement for webmethods because of the infrastructure that webmethods has. It has all kinds of help with EDI documents, it has a graphical builder (which I find to be a PITA), FTP / HTTPS integration and loads of documentation. But at the core, babeldoc does what webmethods does - it allows for a linear stepwise transformation of documents. -
dynamic data transformations[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 30 2003 13:56 EDT
- in response to bruce mcdonald
Agreed on the WM GUI. I think that your biggest challenge with babeldoc will be to present a good UI. Of course, I think you've taken the right approach in addressing configurability from config files first. Past a certain point of complexity and past the newbie stage, UIs can often slow down the configuration process (and of course usually involve configurations that are hard to version control). I think the problem with WM's UI is that it was designed first as a UI to a complex configuration language (FLOW or something like that?). What that does is it makes your first few months of using the tool relatively easy. But past that, when you need to start doing really complex mappings or you need to start working with them on a more regular basis and need to be able to quickly make changes, you start to get hampered. If you make the configuration language more legible, so that it's possible to get good with using it, then your first few months might be more difficult but after that, you'll be much more able to deal with complexity. Then, you can still come out with a GUI tool to address the simple cases.
Another way to sum that up is that if you plan on making the simple jobs easy, everything will be great until you need to do something complicated. If you plan on making the complicated jobs easy(ier), then you can always go back and add wizards or gui helpers to make the simple jobs easier, too. -
dynamic data transformations[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 12:17 EDT
- in response to Rolf Tollerud
First things first: Rolf, please do NOT turn this into yet another Java versus MS debate. YOu're way out of your league here because I have extensive experience both with the Java side AND with MS products such as DTS and BizTalk. I have used them and know what you're talking about but they were not sufficient for my purposes when I was working on the project in the past and I would not find them sufficient for use in the future.
It is correct that using DTS does require a lot of hacking around to get anything more than a simple transformation done. If you're mapping from "Vendor1AddressRecord" to "Vendor2AddressRecord", then fine. If you have one vendor with a completely normalized representation of a customer (using a contact point pattern) to another vendor's customer record with a relatively flat structure, you end up having to do a lot of hacking around. Unfortunately, that's a very common scenario when doing a lot of integration transformations. Also, you get into especially hot water when attempting to do something even more complicated, such as the runtime SVG creation the other use talked about.
I don't think DTS is a bad tool; it certainly presents a nice GUI. BUt I think that when you look at it at first, you think it matches the 80/20 rule (80% of what you want to do is easy, the other 20% hard). On extended use, the ratio is more like 40/60, which is just not going to cut it when you have a lot of transformations that you're trying to manage and pipeline through each other. BizTalk mapper is the same way, but unlike DTS, at least it's format is XSL and somewhat open.
The other problem you seem to forget about is that DTS is NOT OPEN. In the situation I mentioned, we were deploying to an HP UNIX box because we had to. I cannot run DTS on that. YOu can bitch and moan about MS's merits all you want but it will not run on UNIX. Not now, and no, even with "Mono", it NEVER WILL.
I don't want to shortchange DTS or biztalk mapper because they are fine tools, just not as full-featured as I'd be looking for. What I do want to do is avoid spiraling into another useless MS vs Java debate that avoids the key issue. If you're on a Wintel platform and DTS cuts it for you, fine, and I'd be glad to hear why. I have no desire or patience to hear about how DTS is the greatest thing ever and after doing a job search on hotjobs you've determined that anyone who doesn't use DTS for transformation services is a fool who will soon be consigned to the dustbin of history. I've heard it from you too many times in the past. -
JSP as a transformation alternative.[ Go to top ]
- Posted by: Marko Milicevic
- Posted on: April 29 2003 15:50 EDT
- in response to Drew McAuliffe
Another good (and arguably more flexible) alternative to XSLT is JSP with XML custom tags.
http://jakarta.apache.org/taglibs/doc/xtags-doc/index.html
http://java.sun.com/webservices/docs/1.0/tutorial/doc/JSTL6.html -
XML/XSL does have its place[ Go to top ]
- Posted by: Race Condition
- Posted on: April 29 2003 14:25 EDT
- in response to Don Brown
What do you mean by "pipelining the transformations"? -
Transformation pipelining[ Go to top ]
- Posted by: Don Brown
- Posted on: April 29 2003 14:59 EDT
- in response to Race Condition
Transformation pipelining is best seen in Cocoon 2. You have the ability to define, in XML, an XML transformation pipeline which contains an XML generator, multiple XML transformers, and a serializer which turns the XML into the output of your choice. This allows your transformations, usually XSLT transformations, to be complete independent of each other. For example, one XSL could transform the XML by replacing <message key="button.add" /> with the appropriate resource. Another one could match certain HTML tags and add fancy Javascript if the correct browser was detected. The Cocoon site, http://cocoon.apache.org, has many more examples.
Don -
Transformation pipelining[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 17:09 EDT
- in response to Don Brown
How does cocoon handle transformation mappings? Does it provide a way to do complex mappings between object trees of hundreds of nodes (e.g., a telecom provisioning order in various flavors)? A way to have a mapping potentially decompose one object tree into a collection of others, of various types? Or combine object trees into one on the other side of the pipeline? How easy is it to work with the files or other information that determines the mapping?
I don't say this as a challenge, just out of curiousity. You say Cocoon2 which may have evolved quite a bit since the original Cocoon I was familiar with. My understanding is that the original Cocoon was mainly using XSL as a way to transform objects serialized to XML into some sort of XML (or HTML, or ...) output on the other side. If that's changed, I'd be curious to hear more. -
Cocoon2 is a totally different animal[ Go to top ]
- Posted by: Don Brown
- Posted on: April 29 2003 18:33 EDT
- in response to Drew McAuliffe
<drew>How does cocoon handle transformation mappings? </drew>
Cocoon 2 sets up a SAX-based transformation pipeline. How exactly the SAX stream is manipulated is up to the transformers you define. A transformer is a SAX ContentHandler (and LexicalHandler) takes SAX events and sends SAX events to the next transformer. Probably the most common transformer is the XSL transformer, but its really easy to write your own that uses your own algorithms.
<drew>Does it provide a way to do complex mappings between object trees of hundreds of nodes (e.g., a telecom provisioning order in various flavors)? A way to have a mapping potentially decompose one object tree into a collection of others, of various types? Or combine object trees into one on the other side of the pipeline? How easy is it to work with the files or other information that determines the mapping? </drew>
Cocoon only handles XML via SAX events. As I mentioned earlier, Cocoon uses a generator to start the SAX events. Again, really easy to write your own generator. Now, Cocoon also has various techniques to aggregate the results of pipelines, split pipelines, and other such more complicated actions I haven't messed with much. If anything, Cocoon is _too_ powerful.
<drew> I don't say this as a challenge, just out of curiousity. You say Cocoon2 which may have evolved quite a bit since the original Cocoon I was familiar with. My understanding is that the original Cocoon was mainly using XSL as a way to transform objects serialized to XML into some sort of XML (or HTML, or ...) output on the other side. If that's changed, I'd be curious to hear more.
</drew>
I'm not sure how uptodate this is, but it should explain how Cocoon 1 migrated into Cocoon 2: http://xml.apache.org/cocoon/userdocs/concepts/index.html I admit I'm relatively new to Cocoon, but I've yet to find anything that is better at manipulating XML.
Don -
Cocoon2 is a totally different animal[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 18:58 EDT
- in response to Don Brown
Cool, thanks. I'll check it out. -
the Skin framework could use Cocoon's XSLT processor[ Go to top ]
- Posted by: george li
- Posted on: May 04 2003 04:57 EDT
- in response to Drew McAuliffe
In the book "J2EE & XML", Gabrick and Weiss point out that Cocoon could be integrated directly as XSLT process mechanism in a XML/XSLT presentation framework. -
Benefits without the XML speed problems[ Go to top ]
- Posted by: Gene Kuznetsov
- Posted on: April 29 2003 17:53 EDT
- in response to Drew McAuliffe
Drew expresses the most common XSLT complaint, against XSLT performance:
" 2) It is SLOW SLOW SLOW. I have seen many performance reports that indicate this and my saw first-hand an XSL-based architecture at my last fulltime job that was just a performance nightmare. Not only do you have to deal with the problems of XML serialization, but XSL processors just run a lot slower than other methods of putting together a web page. "
This is certainly the case with the free software engines. But take a look at DataPower's XA35 XML Accelerator, a hardware device which can parse XML and perform XSLT at 100's of megabits per second. That means doing XSL as fast as the wirespeed for your Fast Ethernet network -- likely faster than other methods of putting together a web page. Can your current server-side system fill up a 100 Meg network link with generated pages? Often not.
The idea is that the XA35 can get you all those benefits of XML or XSLT that others in this thread have pointed out (crossplatform, separation of content from presentation, single-source publishing, etc.) without paying the "SLOW, SLOW, SLOW" performance price.
Since XSLT is portable, you can build the app with open-source java engines (e.g., Xalan) and then switch to hardware acceleration for production deployment if necessary.
Check out this http://www.datapower.com/products/xa35.html - XSLT Acceleration for more info. -
Benefits without the XML speed problems[ Go to top ]
- Posted by: Drew McAuliffe
- Posted on: April 29 2003 23:16 EDT
- in response to Gene Kuznetsov
How does your XSL engine deal with scripting? One of the other complaints about XSL is that it doesn't give you a very expressive language for manipulating the transformations. You have to resort to Java or VBSCript (take a look at MS biztalk: it has a nice mapping tool that uses XSL and javascript functions). The problem is that the JavaScript is pretty kludgy and hard to maintain. How does your product support more complicated mappings (e.g., merge and split graphs)? Does it use JavaSCript or vbscript? Also, how does extensive scripting in the XSL file impact performance? Are your performance numbers based on an XSL transformation without any scripting? -
Scripting vs. XML vs. XSLT[ Go to top ]
- Posted by: Gene Kuznetsov
- Posted on: May 01 2003 09:15 EDT
- in response to Drew McAuliffe
There are some capabilities in this area, but the big question is: why do you need scripting? XSLT is Turing-Universal, you could write MS Word in it if you wished. There are some inconvienient shortcomings in XPath 1.0 with date-formatting and other frequently-used data manipulations, but that is being addressed in upcoming XPath 2.0 and exslt (www.exslt.org). Just a matter of adding some additional extension elements / functions to make it more convenient to do certain kinds of processing. -
Cocoon 2[ Go to top ]
- Posted by: Reinhard -
- Posted on: April 29 2003 03:38 EDT
- in response to Nate Borg
I've been using Cocoon 2 (http://cocoon.apache.org) for several years and every day I'm more convinced that it IS the RIGHT choice. It is THE framework for XML applications because:
- Separation of concerns (you can separate between data, view and flow logic --> do the things where they should be done)
- very fast because it is SAX based and supports caching at many places
- it can be easily extended (it is 100 % Java) but the most things can be done without writing a sinlge line of Java code
- the core of Cocoon is its sitemap. the sitemap makes it easy to manage the URI space
And there are many reasons more!
Reinhard -
Re: XSL as a JSP page[ Go to top ]
- Posted by: Marina Prikaschikova
- Posted on: April 29 2003 05:36 EDT
- in response to Nate Borg
See for example XSL taglib from Coldtags suite:
www.servletsuite.com/servlets/xsltag.htm
You can provide XSL data as JSP code -
grid XSLT[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: May 01 2003 14:01 EDT
- in response to Nate Borg
With grid computing, the whole "don't have enough CPU" problem goes away for XSLT. It's not too hard or expensive to put together a teraflop grid of XSLT processing. We have customers using Coherence to do it, but you could also use JavaSpaces, RMI, or even a Tomcat farm behind a h/w load balancer!
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster! -
OXF[ Go to top ]
- Posted by: Erik Bruchez
- Posted on: May 01 2003 19:29 EDT
- in response to Nate Borg
<plug>
Everybody interested in considering XML and XSLT as an alternative or
complement to JSP / Struts should consider OXF. The core of OXF is
XPL, an XML pipelining language that allows you to combine XML
transformations of any kind. XPL is very easy to learn and provides
built-in conditionals, aggregation, XPointer support, WXS and Relax NG
validation, caching, and more. In OXF, XPL is built on top of SAX for
maximum memory efficiency.
OXF can be used to build Web apps, standalone apps, or can be embedded
in any Java application that needs XML processing without the burden
of directly using JAXP. For Web apps, you can use OXF in conjunction
with Struts (an architecture we call Model 2X), or standalone, thanks
to a series of XML processors including XSLT, SQL, XForms, basic
serializers and generators, with many more coming up in the next
version. You can also write your own XML processors in Java.
One of the biggest problem users face when considering XML/XSLT for
their presentation layer is the lack of methodology. With OXF, we
provide a clear architecture, either when combining XML/XSLT with
Struts, or when using OXF standalone.
For more information: http://www.orbeon.com/oxf/.
</plug>
XSLT performance has rarely been an issue for us. As always it depends
on what type of application you want to build. Building a Web app for
20 users is not the same as building a public Web site with hundreds
of thousands of users.
See also the article about JavaServer Faces and XSLT integration that
we published on TheServerSide a couple of months ago:
https://www.theserverside.com/resources/article.jsp?l=BestBothWorlds
-Erik -
Is it possible to get the source distribution of skin framework?[ Go to top ]
- Posted by: george li
- Posted on: May 04 2003 04:51 EDT
- in response to Nate Borg
where to find the source files of the examples? -
JavaOne Session on XML and JSP[ Go to top ]
- Posted by: Erik Bruchez
- Posted on: May 08 2003 18:30 EDT
- in response to Nate Borg
I'll be bold and place another plug: we will have a JavaOne session on the integration of XML/XSLT and JSP/JSF. More information is available here. -
Source Distribution[ Go to top ]
- Posted by: Tom Marrs
- Posted on: May 14 2003 13:41 EDT
- in response to Nate Borg
Is it possible to get the source distribution for the Skin Emax article? Please
include a document describing the Jar files used so I can recreate this. Thanks.
Tom