|
Shold learn XSLT?
I work with Perl for several years now and making an attempt to learn XSLT for one of my projects. I can already use Perl and Templates for this. I just wanted to try somehting new.
Is it worth investing time and mental resources to XSLT?. Is it worth doing it. What new paradigm it teaches which can help me to progress technlogically. ( besides resume maker).
I found zvon.org as best resourcce for learning XSLT step by step. I found it better than reading the O'reilly book because the concept can be tried out easily.
I found Perl's XML::XSLT module not good enough to handle standard things which can be Handled by Mozilla Parser such as name().
I am good enough with basic HTML or Javascript
Many thing I read on the net is about using XSLT with Java or MsXML, DOM parser etc.. which I haven't explored. ( I haven't found need to explore)
I like to get good advice on learning XSLT, keeping my background in mind.
Thanks..
For your kind help.
Perl programmer
Tuesday, February 24, 2004
Subscribe to this mailing list: http://www.mulberrytech.com/xsl/xsl-list/
I used XSL to convert XML into HTML for a flexible report generator. Simple task; took me a month. XPath - there's finally a more verbose language than COBOL.
Bathmophobic skier
Tuesday, February 24, 2004
yes, learn it. why? because if you do it right, it's a declarative language and will force you to think that way for a bit.
(note: if you already know, say, prolog, this won't be such a mind-bender.)
mb
Tuesday, February 24, 2004
It depends, do you still want work in IT 3 years from now? :-) If not, skip XSLT. Otherwise go for it. I suspect that the avarage programmer (and certainly web and database programmers) will find that 10-25% of the work that they do will include XSLT's by that time.
K
Tuesday, February 24, 2004
"I suspect that the avarage programmer (and certainly web and database programmers) will find that 10-25% of the work that they do will include XSLT's by that time."
Are you being serious? If so, then I respectfully offer up the observation that you are deluded.
The last time I worked on XSLT was some 3.5 years ago (where it worked brilliantly, as a sidenote, as have many other fringe technologies). Do you think that XSLT is some fringe technology that's on the verge of become a core part of our work?
.
Tuesday, February 24, 2004
I still don't understand the point of XSLT... maybe somebody can clue me in?
I've build several complex web sites that have to have the capability of being displayed in serveral formats (HTML, plain text, WAP/WML, light HTML for smartphones, etc). The sites all database driven and they generate output using various templates.
Database
-> Templates
-> HTML, WAP/XML, Text, XML, etc
Now it seems with XSLT, I should do something like this:
Database
-> XML Templates
-> XSLT
-> HTML, WAP/XML, Text, etc
Which is basically generate XML and then add an extra step (and another language) to convert that XML into all the output formats that I need. What's the advantage of this?
Almost Anonymous
Tuesday, February 24, 2004
XSLT is somewhat similar to AWK. What AWK is for text files, XSLT is for XML.
However, XSLT is a much more declarative language. If you haven’t been exposed to declarative languages before, there might be some learning curve there. However, the exposure to a declarative language might change the way you use other programming languages and write your programs and “This is a good thing”.
If you are going to use XML a lot, learn XSLT.
Alexander Chalucov (www.alexlechuck.com)
Tuesday, February 24, 2004
An example of the usefulness of XSLT from my own experience. I wrote a program which produced a doctor's note and stored it in a data format. I had a method in one of my objects that would spit out an XML representation of the note. To produce a printed version I created an XSLT to turn this into XSL-FO and thence to PDF or RTF as the client wanted. To change the printed document to a different format, a different order, give it a different logo, change the name of the practice or whatever, I only had to provide a slightly modified XSLT. Same thing with printing prescriptions. This involved a small subset of the info from the note but with the correct XSLT I could print out just that.
It provided a clean way to separate the printing logic from the data objects and didn't need to be recompiled whenever a change was needed.
My take is that XSLT is extremely painful to learn but very useful in a small number of situations.
name withheld out of cowardice
Tuesday, February 24, 2004
You need XSLT if you have XML files for some reason, and you want to convert them into some other kind of text file for some other reason.
Examples include transformation between different XML schemas, or composing web pages in XML and publishing them in HTML.
If you don't already have data in XML, and/or if you already have a conversion path between input and output format that doesn't require XSLT, then you don't need it. XSLT is really just a specialized conversion mechanism for data in XML format.
Chris Nahr
Tuesday, February 24, 2004
I guess what has got me is that I've seen alot of people and heard alot of discussion from people who produce XML *solely* to run it through XSLT to produce some other format. Obviously, if you already have the XML to begin with than XSLT is an obvious choice. I just think everyone else is radically overengineering -- just wondering if I'm wrong on that.
Almost Anonymous
Tuesday, February 24, 2004
Almost Anonymous ,
I'd like to chime and explain the forever-increasing layers of abstraction of web development.
1) Database stores the content
2) The content is pulled from Database into an XML document
At this point you have the content in a format that can produce a lot of different documents. You won't have to write new SQL and Code templates to produce your content for another use (web, book, magazine).
3) Use XSL to transform the XML document into the document you need. For example, you use XSL to transform that XML into a XHTML compliant document.
At this point you have the content in a format that can be used for all the different web-enabled devices and printing from said web-enabled devices when apply CSS to it. (Web Browsers, handhelds, etc...) Not all the user agents (things that show HTML) will honor the specified decleration of "this CSS is for handhelds", etc....
4) Now you can create different CSS (style sheets) to apply to your XHTML and have a totally different look. You can revamp the look of your entire site by only changing the CSS file and the graphic images. You don't need to redo any coding templates that produce the XHTML. You just redo your CSS and make new graphics.
At each step above you reach a point where you do not have to go back wards to change certain things.
When you want to change the look of your site, change the CSS and everything else will be unaffected. Want to make your site more useable on a handheld? Change the CSS.
When you want the page to no longer display a certain thing for the web, but still for the Book version, change the XSL for the web version. But leave your Book XSL alone, and you still don't have to change the XML or the code that pulled the content out of the database.
Obviously when you want add something that the existing documents won't know how to handle you will have to change things on multiple levels.
An example of this stuff at work may be happening with O'Reilly's Safari book shelf web site.
All there content started out in books. I'm assuming the books were stored in XML (isn't it DocBooks or something, i forget the specific name for it). The content was probably transformed into XHTML and they use CSS to apply the look of the site. (I'm leaving out a lot of details because I'm not really sure they did this, but it just seems obvious. Not to mention they probably store all transformed content in a database just to make it easier to manage and deliver.)
(The above description of the many layers of web development are probably not used on more than a fraction of the sites out there. Which parts you use will obviously depend on your needs.)
So .... Should you learn XSLT? Do you forsee your job needing to read and utilize XML documents? That will answer your question.
michael sica (michaelsica.com)
Tuesday, February 24, 2004
The only limitation with this model is that once you've generated the XML file you limited to what it contains. This assumes a 1-to-1 mapping between what content to display for regular XHTML users, web-enabled devices, wap browsers, etc. The structure of a WAP version of a website generally has nothing in common with regular structure of the website -- that's not something you can codify in the above mentioned process.
Almost Anonymous
Tuesday, February 24, 2004
If XSL wasn't such a PITA, Michael's idea would be great. But XSL is a PITA, and doing things like munging and formatting text, iterating over collections, etc... is simply pulling teeth in XSL.
The question I have is this:
If XSL is so great, why did Microsoft (a big XSL proponent) eschew it as the templating mechanism for ASP.NET?
Sassy
Tuesday, February 24, 2004
Is WAP still used? :)
It could be handled at the XSLT level. Just leave the stuff out of the XML document that you aren't going to display in the [insert_name_of_document_here].
The XML will have 100% of the content.
Then apply XSLT and maybe the XHTML will only have 80% of that.
---
Reality check.
I doubt anyone really uses all this. This is more of a description of a big grouping of all the different powers of each individual technology. Most sites just have code files pull stuff from a DB, then when they need a different display, they probably just call the same code files and display it differently.
michael sica (michaelsica.com)
Tuesday, February 24, 2004
Almost Anonymous - that's something that Microsoft has addressed quite nicely in the .NET framework. Objects can implement IXPathNavigable. (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemxmlxpathxpathnavigatorclasstopic.asp for details). It allows objects to look like (and be transformed using XSLT as if they were) XML documents without any XML being generated, which avoids having to fetch a superset of data for all of your output types.
Even without this I like using XSLT in designs though - it forces rendering code to be kept separate.
r1ch
Tuesday, February 24, 2004
"Is WAP still used? :)"
Probably not. I had a WAP phone a few years back and did some simple development with it. Now I have P800 w/ Opera.
"The XML will have 100% of the content."
There is still the implication of a 1-to-1 correspondance between URL -> Content -> Output. At least with WAP, you can't even put everything on one page!
But yes, I get the idea. That's one bloated XML file! For small screen devices I might only want to display 50 character link descriptions rather than usual 100-150. So I'd have to include both or does XSLT give me the ability to truncate text (and add an "...").
Give me programmable templates (in the same language I do everything else in) or give me death! ;)
Almost Anonymous
Tuesday, February 24, 2004
XSLT lets you truncate a string, but be prepared for a ridiculous learning curve.
I had to do a simple counter in XSL once, you know, iterate over some data and count the iterations. I nearly killed myself, my computer, and the W3C that day.
Sassy
Tuesday, February 24, 2004
XSLT is very useful for transforming XML into different forms of XML. As mentioned before, it takes a little getting used to because of its declarative nature.
The alternative to XSLT is to write a DOM or SAX-based parser in <language-of-choice> and procedureally crawl through it and output text. I've done both and XSLT ends up being much easier to debug. It's a PITA to do certain kinds of formatting in XSLT, so sometimes I cheat and end up putting multiple formats of the same data in the original XML when I have control of it. I know this is a hack.
It's very good when you have some object (an article or a product definition) in XML already and you want to display it as XHTML.
It's very good when you need a simple way of translating your_file_v1.xml into your_file_v2.xml.
It's very good when you need to translate an internal XML document into a pre-defined format used by a 3rd party. Say you have a PurchaseOrder format you use in your company and you do business with 3 different vendors who all have their own seperate PurchaseOrder formats. You just pull the data out of your database into one PurchaseOrder.xml file and use XSLT templates to produce XML files for the vendors.
Richard P
Tuesday, February 24, 2004
How exactly do you debug XSL?
Sassy
Tuesday, February 24, 2004
Sassy - there are plenty of XSLT debuggers around ( http://www.google.co.uk/search?hl=en&ie=UTF-8&oe=UTF-8&q=XSL+OR+XSLT+debugger&meta= ) but you can get often get away with just the error messages from the processor and writing stuff to the output.
r1ch
Tuesday, February 24, 2004
> The alternative to XSLT is to write a DOM or SAX-based
> parser in <language-of-choice> and procedureally
> crawl through it and output text.
Quite true. The coming X# seems like perfect fit for this kind of development because all the iterators for XML are built into the language, so you can as easily write for-each and value-of logic, as well as procedural logic. I wonder whether the Java world will come up with something like that. If done well, it's way better than XSLT.
On the other hand, at least on the MS platform (MSXML) XSLT can be easily extended with scripts. It's possible with Xalana (java) too, but it involves much more writing (as all java-related stuff).
Something I am really mising in XSLT is the capability to update (not produce new ones) XML documents. It can be done much easier with procedural language.
Alexander Chalucov (www.alexlechuck.com)
Tuesday, February 24, 2004
Another advantage of XSLT that apparently hasn't been mentioned is that it can be used as a scripting language.
I've used it to allow non-programmers (but IT people nevertheless) to easily modify the rules of execution for a system I designed and it's worked like a charm. These people are used to do lots of SQL, and XSLT is very (actually, kind of) similar to it.
One good thing about XSLT is that is in the process of maturing and has a lot of support from the industry, which doesn't happen with some other emerging technologies/languages (Ruby, Eiffel, XQuery, etc).
If you have to work with XML, eventually you will need XSL. Some transforming is just too hard to do with DOM/SAX processing.
Dario Vasconcelos
Tuesday, February 24, 2004
"Is it worth investing time and mental resources to XSLT?"
Learn enough of it so you can grab an XSL stylesheet and use it. Don't spend more than a few hours on it.
Tom Vu
Tuesday, February 24, 2004
I have found that the O'Reilly XSLT book http://www.oreilly.com/catalog/xslt/ was enough to get me up and going in a weekend.
As for the 10-25% number, at least that much of the work that I do on a project by project basis uses xslt's. I do some b2b data interchange as well as take industry standard xml documents and transform them to local data stores. Additionally, multiple document presentation formats are also a part of my life. Could I do this with other tools? Yes, however XSL is built to do this and isn't all that difficult to get behind after you get round the initial learning curve.
K
Tuesday, February 24, 2004
"Learn enough of it so you can grab an XSL stylesheet and use it. Don't spend more than a few hours on it. "
Um, I'm going to restate my first statement:
Learn it the right way, that is how to use it in a declarative fashion. It will force you to think in a declarative fashion.
Unless of course your goal is merely to bang something out without understanding it. In which case you're probably not in the situation to ask if you should learn XSLT but rather are being forced to.
(I'll also restate that if you've seen declarative languages before this shouldn't take more than a few hours.)
mb
Tuesday, February 24, 2004
Sean McGrath on XSLT with a ref to Martin Fowler.
http://seanmcgrath.blogspot.com/archives/2004_01_18_seanmcgrath_archive.html#107460104001879880
fool for python
Wednesday, February 25, 2004
XSLT is a PITA to learn, probably because, as another poster noted, it is declarative and most of us aren't used to that. Iterating through things has been difficult but from what I have read the new version of the standard has added a lot of stuff to help us out. I will probably learn that the next time I need to do something with XSLT.
name withheld out of cowardice
Wednesday, February 25, 2004
XSLT might be good for your resume.
I've used it, and it's still working daily in my application.
But is it a stylesheet ? In this case, it's overly complicated : you need a programmer (with a book at hand) to update it.
Is it a script ? Then I suppose most programmers would implement the transformation in much less time in Perl, Python, Ruby, whatever.
GP
Wednesday, February 25, 2004
 Recent Topics
Fog Creek Home
| 
