I am trying to use Saxon to programmatically generate an XSLT. This is a similar question to Create xslt files programmatically, but as there was no acceptable answer to that question I am asking again, specifically around Saxon which at one point claimed to support this.
According to http://saxon.sourceforge.net/saxon7.0/api-guide.html, "This document describes how to use Saxon as a Java class library, without making any use of XSLT stylesheets."
(answering the other question I referred to above) and then serialize that to a stylesheet that could then be reloaded and executed later, but I already pretty much figured out that isn't going to happen.
If Saxon isn't the answer, what Java library will support any of this?
By the way, doing any and all of this using .Net is trivial. Unfortunately I need a Java solution for this.
Any help is greatly appreciated.
Well, for a start, there have been 26 major releases and innumerable maintenance releases of Saxon since release 7.0, so forget anything you read there.
It's not clear from your question whether you want to write your XSLT code generator in Java or in XSLT. I can't see why you would want to do it in Java rather than XSLT, but neither is difficult. The main problem with your question is that you don't explain why you think it's a problem. Generating an XSLT stylesheet is just like generating any other XML document: what's the problem?
I figured this out a while ago, and thought I would share my answer. This may or may be an answer for Create xslt files programmatically as well, but since that was not my question, I won't assume that.
The answer is not to use XSLT (or Saxon) at all. Originally I wanted an API with which to generate an XSLT model where the rules for transforming a particular (xml) tree structure are known programmatically. Then the model could be persisted as a style sheet so that it could be reloaded and used to transform another tree with the same structure again. Sure I could programmatically create a DOM containing an XSLT style sheet document, but why would I want to? It's inefficient for one - creating and saving a DOM with all the XSLT syntax (tedious), and then reading it using SAXON, etc. I'd rather have an API that natively understands XSLT - maybe one that has an XSLT model that can just be programmed and then serialized?
Anyway, the answer to my problem is just to use SAX. Since I know the particular transformation rules for my tree programmatically, I simply created a handler that processes the stream using the rules, and I'm done. In the end there's no XSLT style sheet that can live outside the program, but I'll live with that.
And I take back what I said about .Net supporting my first approach. I thought it would so it's just a reminder to check your assumptions before you post.
By the way, an answer to my question suggested that it was easy to accomplish but rather than outline how to do it, I was just questioned why I would want to. Can we at least try to answer a question if we also feel we need to ask someone why they are asking a question?
Related
I am using BizTalk MAP and inside BizTalk map I am using table looping, table extractor, Scripting, looping functoids.
The same can be achieved in BizTalk map by referencing XSLT.
so Performance wise, which method would be better using BizTalk Map or BizTalk map referencing XSLT.
In fact, your visual BizTalk map created with the BizTalk mapper, is XSLT. Only your functoids are libraries/functions which may be either XSLT or inline C# code. One way you can check this is to right click your .btm map and click 'validate'. In the output window, you will see the link to your XSLT file.
Performance is very tricky with XSLT. You can write your XSLT in a very good way or in a way that it's not meant to be used.
For a pretty basic mapping, performance differences will be there, but will be pretty minor (if any at all). As Dijkgraaf says: the only way to check this, is to test it.
If your current implementation gives you performance issues, try writing it purely into XSLT, which is very optimized either way. Try taking different approaches/techniques.
In general, I would always recommend writing XSLT instead of using the mapper, but let's be honest: this is personal preference.
I wrote a blog post on this, check it out here: https://pvandenheede.wordpress.com/2016/09/20/the-case-for-xslt/
XSLT benefits
Import generic or common stylesheets
Use common templates if your schemas are lined up
Inline comments
Disable (comment out) code blocks during debugging
Easier review
Tracking changes in your source repository is possible
Merge from branches is possible
I'm always in favor of using XSLT, only reason Microsoft created functoids and biztalk map, so developers will just do drag and drop. If you're not interested learning XSLT at all.
I'm might be the strange one in favor of using the mapping tool, as said it also produces XSLT.
I think its easier to talk about what is happening in the map with colleagues, since it's visualized, and easier for others to maintain, since not all are that used of coding XSLT.
The only three times I had performance issus with the generated XSLT was
Using one XML as a lookup table in a two incoming XML map - A bug in BizTalk 2006, solved with 2006 R2.
When getting connection strings from SSO - Solved by moving the Script to a global Functiod running once
Using Cumulative Maximum - solved by this method
i think it depends of situation but bizTalk create a lot of variables, code, etc when you create a map using map GUI. I have an experience when i made a map in a map GUI but then just cleared it and leaved in XSLT.
I'm in a bit of a weird spot. Due to events too ridiculous to list here, I'm working with a system that uses an unknown XSL engine. I'm fairly certain it's MSXML. The problem is that I'm not entirely sure which version (this is important). The original devs aren't available, and I have very limited access to the back end. What I do have the ability to do is author content (that gets fed through the XSLT sheets) and to edit the XSLT itself. Given these two abilities, is there any way I can make the parser report its version? Anything like PHP's phpversion()? Maybe even a standard way to report the XSL engine vender and version?
I'd be very willing to write a feature check sheet, if I could just find a list of XSL engines, and features unique to each.
You can process this XSLT stylesheet with your XSLT processor, it outputs some system properties, including the Microsoft msxsl:version.
<xsl:value-of select="system-property('xsl:vendor')"/> will tell you if it is Microsoft, but there is no property in XSLT 1.0 to tell you the version, only in XSLT 2.0.
Is XML something required to use in modern games? Sense I'm trying to make game that will be programmed like a professional programmer did it, So should i use XML in my game or it is just an optional thing, Why and Why not?
There's nothing wrong with using XML if it solves your problem. There's nothing wrong with not using XML if it isn't the best option for solving your problem.
If you want to store data in an a format which is easy to query, then XML is not a bad option. If you're look for space efficiency, XML is not a good option. If you are looking for cross-platform features, XML is a no-brainer compared to binary formats.
JSON is another option which is very simple and very lightweight.
In short, it depends on your requirements. If you want more direction you'll have to give more information.
Use whatever works for you. Don't judge your tools based on whether something is considered "uncool". If it works for you and helps you create maintainable and flexible code and data, use it.
Now specifically for XML - that's definitely a format that is widely used and has libraries for virtually every platform. I've worked on a recent Xbox 360 and PlayStation 3 title that made use of XML.
I want the DocBook documents in my SVN repository to look nice if someone looks at them in a web browser. I've started to write a CSS stylesheet, but I think that it will have significant limitations -- particularly ones regarding hyperlinks.
There is a large body of DocBook XSL stylesheets at the DocBook site , but they don't seem to be appropriate for browser rendering. I don't want to generate static documents and put them into SVN. I want them to be basically readable for other developers without much hassle.
I could write my own browser-appropriate XSL stylesheet to convert DocBook to HTML, but it seems like someone else must have already done this. I just don't know where to find it.
In a past life I used wysiwygdocbook: http://www.cs.hs-rm.de/~werntges/proj/wysiwyg-dbk01.html
You are right, the DocBook XSL stylesheets are very heavy, and are not really suitable for running in a browser. The DocBook Wiki lists some CSS stylesheets, perhaps one of those might work for you?
The only one I have experience of is the one which XMLMind XML Editor apparently uses to present DocBook documents.
I've done some XSLT+CSS very basic and incomplete implementation for browserside DocBook styling. You can check it out here http://github.com/arsi/db2xhtml
But I would like to see more advanced project if available somewhere!
[Edited because I misread the question]
You certainly wouldn't want to run the stylesheets via a browser and the PI but then you wouldn't want to do that for any reasonably complex content. Do it server side if you're running over a web server or as a batch task. Is there any way that you can interpose a server side process in svn?
DocBook is a complex 'language' and capturing even most of the subleties of DocBook is very difficult. Using the DocBook XSL is not complex at all and I really would recommend you go in that direction if you can. The stylesheets are designed to be customised and are extremely well documented by Bob Stayton in DocBook XSL: The Complete Guide.
After quite a bit of searching, I believe the answer is "there is not a nice XSL stylesheet for client-side DocBook rendering," besides the bespoke ones like the one I implemented.
Typically you'd produce a 'rendition' for reading/display. The rendition can either be PDF, a single HTML page, or set of HTML pages. It's rare that you deliver docbook directly to web.
Can I ask what you're trying to accomplish and why?
Is this for internal delivery or external?
I hate getting the question that asks "can your technology do X?" It assumes a lot of knowledge about the product (plus, usually the answer is "yes" but that doesn't answer the real question). It's always best when I ask -- "what are you trying to accomplish" -- so I can tell you whether or not any piece of technology is a good fit (or I can point you to some other piece that's a much better fit, or a better way to go about it).
I am in the preliminary stages of planning a project with a client to redo their current website. I took a look at their current site to see what issues they are currently dealing with and upon inspection I noticed that every page is being rendered entirely using XSLT. I am familiar with XSLT, I have used it to render custom controls that need to be refreshed often on the client-side, but never to render an entire page.
Help me become less ignorant, what could be the reasoning behind this? What benefits or disadvantages does this bring to the table?
Server-side:
Advantages:
Clean, concise templates
An easy way to process XML data into HTML
Reasonably fast
Disadvantages:
Programming model unfamiliar and uncomfortable for many procedural-language programmers
Awkward if some or all source data is not in XML
Can be very slow when not used carefully (small changes can have large repercussions)
Client-side:
Advantages:
A convenient way to off-load processing onto client code, where scripts can potentially have much better knowledge of how best to format the resulting HTML.
Disadvantages:
Browser support is all over the map.
Google won't thank you.
Sounds like they did it because they knew XSL-T very well and already had XML data on hand.
I wouldn't like the solution myself. XSL-T isn't the easiest thing to read or write. It doesn't lend itself well to visualizing how a page will look. It cuts designers and web developers out of the process. And it doesn't internationalize well. There's nothing equivalent to Java resource bundles that can pull out locale specific information. I don't consider cut & paste a good solution.
XSLT on client side
Disables progressive rendering. User won't see anything at all until entire stylesheet and data is loaded completely.
Not supported by search engines and other crawlers. They'll see raw XML.
Not supported by older/less advanced browsers.
XSLT in general
Unless you carefully design your stylesheets, they may quickly become difficult to maintain:
with numerous templates it may be very difficult to figure out which templates are applied.
verbosity of XSLT and XML syntax make it hard to understand anything at glance.
XPath tricks are tempting, but nightmare to modify later.
I think XSLT is great when built the right way(We use a framework of templates at work).
Sounds like the All-singing-all-dancing XML fetish.
Since you can do anything with XSLT, might as well do everything. I've had people ask why a data warehouse isn't just XSLT transforms between input, data mart and reports.
Advantage. Everything's in XML.
Disadvantages.
Not very readable. Your page templates are bound up as XSLT transformations with confusing looping and conditional processing features.
Any change to page templates requires an XSLT expert, in addition to the graphic designer who created (and debugged) the HTML and CSS.
Biggest benefit: platform neutral way to render xml
Biggest disadvantage xsl is difficult to maintain
I've once had to work with an xsl over 4,000 lines long that also includes several other xsl templates. Now that was hard to work with!
The answers above provide a good survey of some of the advantages and disadvantages of XSLT. I'd like to add another disadvantage. We have found that you pretty quickly run into scalability issues when using XSLT for moderately large datasets.
When processing XML files, XSLT must load the entire document into memory. With Xalan, this consumes roughly 10x the size of the input file (saxon has an alternative DOM implementation that uses less memory). If any of your input datasets grow beyond a couple of hundred megabytes, your XSLT processor might just flake out.