Sams Teach Yourself Xslt In 21 Days Pdf Converter

Goldfarb's XMLbooks.com Charles F. Goldfarb's All the XML Books in Print™.

Or nearly so 387 Unique Titles Listed But beyond this, my son, be warned: the writing of many books is endless, and excessive devotion to books is wearying to the body. Ecclesiastes 12:12 (Thanks to Tim Bray for the biblical scholarship) Ed Mosher, Ray Lorie, and I invented the first modern markup language in 1969, IBM's 'Generalized Markup Language' (GML). It led to SGML, HTML, XML, and countless applications and variations on the theme. But strangely, considering that markup is for documents, for the first two decades in which the markup language concept was gaining its now universal acceptance, hardly any books were published on the subject. Well, the last five years have more than made up for the first two decades! In fact, despite the past two years having the worst sales ever for computer books, the number of XML titles tripled (although there has been a 5% decline in the past six months). This list includes all the books I know of with substantial content devoted to XML and its closely-related standards and technologies.

It is shorter than the lists you get from bookstore search engines because it excludes editions earlier than the current one and books that are out of print or unavailable from Web vendors. (There are a few out-of-print books that are still relevant and are readily available.) I've annotated the list in varying detail, depending on how well I know the book and its authors.

• • • • • • • • • • • • • • • • • • • • Click on the book titles for descriptions, reviews, and prices. Click on 'Author's site' for details, updates, and errata. The targets of these links open in a single separate window. Books I can personally recommend These are books from the Definitive XML Series that I edit for Prentice-Hall PTR (or of which I am an author). XML isn't HTML with a capital X.

It requires new ways of thinking about Web publishing and software development. The authors of these books have gotten the message and know how to share it with you. I recruited most of them personally for my book series because I know they are genuine experts. In all cases we worked together to make their books accurate and clear, which is why I am able to recommend the books from personal knowledge. Introduction to XML, its major applications, and tools Everyone involved with the Web needs to know about XML: content creators, Website developers, programmers, and — most of all if you want your projects funded — managers.

What reviewers have praised most about The XML Handbook is its ability to reach all these people, while still maintaining the accuracy and completeness that its technical readers require. So much has happened in the XML world since the last edition was published that we've prepared a revised and enhanced fifth edition with over 1250 pages and two CD-ROMs. Goldfarb, Paul Prescod Other editions also published in Chinese, German, Italian, Japanese, and Spanish. This is our largest edition ever!

The comprehensive revision covers Web services, rich clients, XML on the desktop, forms, publishing, voice, wireless, and XML security, to name a few of the topics. There are revised and enhanced tutorials on XML 1.0/1.1, XPath 1.0/2.0/XQuery, XSLT 1.0/2.0, XML Schema, XSL-FO, Semantic Web, and more. Its two CD-ROMs contain 200 genuinely free, no-time-limit software packages, major trialware, and XML-related specs. The Handbook does not claim to teach XML programming, a fact that some Amazon reviewers have failed to note. (See below for books that do.) However, since 1998 it has been the trusted resource for XML technologies, tools, and applications for more than 100,000 developers, architects, and managers — of both code and content. Program development with XML Contrary to misuse in the popular press, and by some experts who ought to know better, XML isn't a programming language.

It is a markup language, of course, and that means it's a data description language. You use normal programming languages, including scripting languages, to develop XML applications. These books show you how. 2.1 General principles and techniques Lars Marius Garshol For experienced developers, this book provides thorough and systematic coverage of XML application development: DOM, SAX, XSLT, XPath, schemas, and all the important APIs and techniques. The author was a designer of SAX and creator of the SAX Python translation. 2.2 Specific applications Charles F.

Goldfarb, Priscilla Walmsley Microsoft Office 2003 Professional Edition has finally brought XML to the rest of us. Thanks to its native support for custom XML schemas, developers can use the world's most popular office suite as a smart client and XML editor for business integration, content management, and Web services. This book shows you step-by-step how to tap Office's power for your own applications. Adam Hocek, David Cuddihy XML is not a spoken language, but thanks to VoiceXML, it is the language of choice for developing spoken interfaces. If you want to voice-enable your applications and Web sites, this book speaks your language. Schemas and DTDs Nature abhors a schema-less database equally as much as she abhors a vacuum. Create a data table in a spreadsheet and the program will immediately search for field names, and supply them even if you fail to.

Java & XML; Sams Teach Yourself XML in 24 Hours, Complete Starter Kit (3rd Edition) (Sams Teach Yourself in 24 Hours); XSLT Cookbook, Second Edition. Sams Teach Yourself Ajax, JavaScript, and PHP All in One; Sams Teach Yourself Django in 24 Hours; Sams Teach Yourself Ruby in 21 Days; Search engine.

Although XML will let you create a document without an explicit formally-written schema (also known as a 'document type definition', or DTD), the benefits of having one are enormous. These books make the job easy, whether you write out the schema using XML markup declarations, XML Schema definition language, or another schema language. Priscilla Walmsley The W3C's XML Schema spec offers an incredibly powerful — and complex!

&mdash schema language, with such new capabilities as strong typing, modularity, inheritance, and identity constraints. This book was written by one of the developers of the language. It carefully guides you through the complexity so you can tap that power for your own projects. The book has won 15 five-star reviews at Amazon, with universal praise for clarifying the near-incomprehensible W3C spec! XML transformations The key to processing XML is being able to address its structures and data and transform them into a new XML document.

XPath and XSLT are the W3C recommendations that govern this process. These technologies affect everything from programming to database design, and for many developers they require a new way of thinking about those problems. This book will help you along the XPath and transform your development experience! Ken Holman Nobody has taught XSLT and XPath to more people than Ken Holman, chair of OASIS's XSLT/XPath Conformance Technical Subcommittee and long-time leader in the XML community.

In this book, he draws upon his popular live training materials that have been used by thousands of developers. Rendering XML G.

Ken Holman The existence of this website is proof — if anyone needs it — that people like to get information from books, with their proven page-oriented navigational tools and sophisticated formatting. XSL-FO is the W3C Recommendation that lets you do this job for your own data.

Ken Holman has taught thousands how, using the examples and insights in this book. Facebook Account Hacker Pro Plus V3 on this page. XPath 2.0: The next generation The ubiquitous XPath is being extended to handle datatypes and other things.

A new XSLT and an XML query language are being built on top of it. These books show you how to put these new languages to work. Dmitry Kirsanov Most websites today are broken: they lack a consistent semantic and media-independent representation of content. XML helps solve that problem, and the key to applying XML to Web development has always been XSLT transformations. Now XSLT 2.0 has added powerful new capabilities to the repertoire of website developers. Dmitry Kirsanov is both a graphic artist and a programmer. He shares the insights of both professions as he shows you how XML and XSLT 2.0 can — literally!

— transform your website. Learning the foundations of XML XML is a proper subset of SGML and the XML Recommendation is much shorter than the SGML International Standard. But the subsetting isn't the only reason for the shorter document.

The XML spec is written for parser implementors and deliberately doesn't discuss applications, philosophy, style, alternatives, and other usage issues. I don't claim that you need to learn SGML in order to use XML, but I think it would help you use it better. Goldfarb (Edited by Yuri Rubinsky) Here is the official ISO Standard, annotated by yours truly (who led the technical work and was Project Editor of the Standard). I've added a structured overview of the complete language that introduces every term and concept in context. This book has been in print since 1990 and was the essential reference used by the W3C Working Group when designing XML. All the books on XML Here's an alphabetical list of all the ones I know about, including those previously mentioned (but excluding some product-specific titles).

I've tried to eliminate books where XML is covered only incidentally. I've also eliminated previous editions of current books, and books that are not available from online vendors. However the list does include books that are not yet in print. (And, inevitably, books that never will be in print — vaporware occurs in computer book publishing just as in other areas of the computer industry!) The books are classified by principal XML-related topic.

Books may appear in more than one classification as they may cover many topics, and classifications overlap. Some books may be classified incorrectly: I haven't read them all and you can't always tell a book by its cover!

• • • • • • • • • • • • • • • • • • Databases and metadata by Steve Muench by Serge Abiteboul, Dan Suciu, Peter Buneman by Zohra Bellahsene by Mark Graves by H. Blanken by Brett McLaughlin by Ben Chang by Adrienne Tannenbaum by Mark Scardina, Ben Chang, Jinyu Wang by Ben Chang, Mark Scardina, Stefan Kiritzov by Judy Skubal by Graeme Malcolm by Tobias Martinsson by Dejan Sunderic by Kevin Williams, Bryant Likes, Andy Novick, Daryl Barnes, Paul Morris by T. Grabs by Ken Henderson by Daniel Appelquist by Akmal B.

Chaudhri, Awais Rashid, Roberto Zicari by Bhavani Thuraisingha by James Bean by Frank P. Chaudhri Desktop XML by Julitta Korol, George M. Doss by Matthew MacDonald by Simon St. Laurent by Peter G. Aitken by Charles F.

Goldfarb, Priscilla Walmsley Integration by Akmal B. Chaudhri, Mong Li Lee, Jeffrey Xu Yu, Zoe Lacroix, Stephane Bressan by JP Morgenthal by Peter Brown by Jeff Zhuk by Casey Kochmer, Erica Frandsen by John Edwards by Jon Anton, Mike Murphy by Matthew Macdonald by David S. Linthicum by Simon St. Laurent by Thomas Erl by Michel Goossens, Sebastian Rahtz, Eitan M. Gurari, Ross Moore, Robert S. Sutor by IBM Redbooks by Michael C. Rawlins by James Bean by Robie Sen, Tyna Hull, Hussain Chinoy, Robi Sen by Charles F.

Goldfarb, Priscilla Walmsley by IBM Redbooks by Kirstan Vandersluis Navigation and Querying by G. Ken Holman by Jack Park, Sam Hunting by Steven Holzner by Erik Wilde, David Lowe by Howard Katz, Don Chamberlin, Denise Draper, Mary Fernandez, Michael Kay, Jonathan Robie, Michael Rys, Jerome Simeon, Jim Tivy, Philip Wadler by Michael Brundage by Jeni Tennison Programming languages and techniques by Jeffrey P. McManus, Chris Kinsman by Fabio Arciniegas A. By Lars Marius Garshol by Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh by Ellen Pearlman, Lorien House by Robert Hablutzel by JP Morgenthal by Don Box, Aaron Skonnard, John Lam by Glenn Niemeyer, Jeremy Poteet by Beverly Voth by Dov Jacobson, Jesse Jacobson by Oswald Campesato by Arthur Griffith by Craig D. Knuckles, David Yuen by Barry Burd by Brett McLaughlin by Brett McLaughlin by Eric M. Burke by William B.

Brogden, Chris Minnick by Robert Flenner, Michael Abbott, Toufic Boubez, Frank Cohen, Navaneeth Krishnan, Alan Moffet, Rajam Ramamurti, Bilal Siddiqui, Frank Sommers by Andreas Eberhart, Stefan Fischer by James McGovern, Sameer Tyagi, Michael Stevens, Sunil Mathew by Harvey M. Deitel, Paul J. Deitel by Kim Topley by Rashim Mogha, V. Preetham by Robert J.

Brunner, Frank Cohen, Francisco Curbera, Darren Govoni, Steven Haines, Matthias Kloppmann, Benoit Marchal, K. Scott Morrison, Arthur Ryman, Joseph Weber by David A. Chappell, Tyler Jewell by Mike Jasnowski by Paul Whitehead, Ernest Friedman-Hill, Emily A.

Vander Veer by Aoyon Chowdhury, Parag Choudhary by Julitta Korol, George M. Doss by Ibrahim Zeid by Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky by Erik T. Ray, Jason McIntosh by Elliotte Rusty Harold by Theodore W.

Leung by Alex Ferrara, Matthew Macdonald by Charles Oppermann by DJ Adams by Danie Damien, Maharry Foggon by Graeme Malcolm by Larry Lagerstrom by Ellen Pearlman, Eileen Mullin by Randy J. Ray, Pavel Kulchenko by James Snell, Doug Tidwell, Pavel Kulchenko by Simon St. Laurent, Edd Dumbill, Joe Johnston by Christopher A. Jones, Fred L., Jr. Drake by Yasser Shohoud by Tobias Martinsson by Dejan Sunderic by Kurt Cagle by W. Scott Means, Michael A. Bodie by Harvey M.

Deitel, Paul J. Deitel, Tem R. Nieto, Ted Lin, Praveen Sadhu, Tem Nieto by Javier Farreres by Eric Armstrong, Stephanie Bodoff, Debbie Carson, Maydene Fisher, Dale Green, Kim Haase by IBM Redbooks by Jeffrey P. McManus, Chris Kinsman by Roger Jennings by William Routt by Hiroshi Maruyama, Andy Clark, Makoto Murata, Naohiko Uramoto, Kent Tamura, Yuichi Nakamura, Ryo Neyama, Kazuya Kosaka, Satoshi Hada by Mark Riehl, Ilya Sterin by Vikram Vaswani by Daniel Appelquist by Michael C. Daconta, Al Saganich by Reaz Hoque by Harvey M. Deitel, Paul J.

Nieto, Ted Lin, Praveen Sadhu by Alex Homer by Martin C. Allen Wyke, Sultan Rehman, Brad Leupen by Brian Benz, John Durant by Soo Mee Foo, Wei Meng Lee by Mark Wilson, Tracey Wilson by Alexander Nakhimovsky, Tom Myers by Erik Wilde, David Lowe by Doug Lovell by Dmitry Kirsanov by Chris Von See, Nitin Keskar by Johan Hjelm, Peter Stark by Michael Kay Schemas and DTDs by Priscilla Walmsley by Berthold Daum by David Gulbransen by Neil Bradley by Cliff Binstock, Dave Peterson, Mitchell Smith by R. Allen Wyke, Andrew Watt by Eric Van Der Vlist by Lucinda Dykes, Ed Tittel, Chelsea Valentine by Eric van der Vlist Security by Clifford Berg by Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh by Larry Loeb, Jeremy Faircloth, Ken Ftu, Carter Everett, Curtis Franklin, Jr. By Pankaj Kumar by Bret Hartman, Donald J.

Flinn, Konstantin Beznosov, Shirley Kawamoto by Donald E. Eastlake, Kitty Niles by Jothy Rosenberg, David Remy by Brian Nantz, Peter A. Bromberg by Mark O'Neill by Blake Dournaee SGML by Neil Bradley by Eve Maler, Jeanne El Andaloussi by Anisava Miltenova, David Birnbaum by Norman E. Smith by Eric Van Herwijnen by Charles F. Goldfarb, Chet Ensign, Steve Pepper by Javier Farreres by Steven J. DeRose by Peter Flynn Software development by IBM Redbooks by Sean Christofferson, Srinivas Jayanthi, Steven Traut, Wira Pradjinata by Michael Fitzgerald by Steve Muench by Richard Hundhausen, Steven Borg, Cole Francis, Kenneth Wilcox by Lonnie Wall, Andrew Lader by Steve Graham, Simeon Simeonov, Toufic Boubez, Glen Daniels, Doug Davis, Yuichi Nakamura, Ryo Neyama by Michael Floyd by Scott Short by Jeffrey P.

McManus, Chris Kinsman by Bill Brogden, Conrad D'Cruz, Mark Gaither by Carsten Ziegeler, Matthew Langham by Lars Marius Garshol by Keith Wood by David Jorgensen by Sandeep Chatterjee, James Webber by Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh by Ellen Pearlman, Lorien House by Robert Hablutzel by Jake Sturm by IBM Redbooks by Don Box, Aaron Skonnard, John Lam by Glenn Niemeyer, Jeremy Poteet by Beverly Voth by Dov Jacobson, Jesse Jacobson by Michael Yawn by David Weiss, Kurt A. Gabrick, David B.

Weiss by William B. Brogden, Chris Minnick by John Edwards by Kirk Hausman, Ed Tittel by Amit Kalani, Priti Kalani by Microsoft Corporation by Mike Gunderloy by Amit Kalani, Priti Kalani by Kenneth S. Lind by John Paul Mueller by David Carlson by Mark Scardina, Ben Chang, Jinyu Wang by Theodore W. Leung by Dick R. Miller, Kevin S.

Clarke by Yasser Shohoud by Tobias Martinsson by Berthold Daum, Udo Merten by IBM Redbooks by Naresh Apte, Toral Mehta by Jeffrey P. McManus, Chris Kinsman by Roger Jennings by Dreamtech Software India by James A. Larson by Chetan Sharma, Jeff Kunins by Jeffrey Griffin, Carlos Morales, John Finnegan by Peter Darakhvelidze, Eugene Markov by Mikael Hillborg by Brian Proffitt, Ann Zupan by Hiroshi Maruyama, Andy Clark, Makoto Murata, Naohiko Uramoto, Kent Tamura, Yuichi Nakamura, Ryo Neyama, Kazuya Kosaka, Satoshi Hada by Daniel Appelquist by Ted Wugofski, Natanya Pitts, Ed Tittel by Sean McGrath by Scott Bonneau, Tammy Kohl, Jeni Tennison by Ajay M. Rambhia by Fabio Arciniegas A. By Michael C. Daconta, Al Saganich by Dan Wahlin by David Morrison, Brian Benz, J.

Minatel by Kip Hampton by Altova by Henk-Evert Sonder, Jonothon Ortiz, Adam Sills by Emily A. Vander Veer, Rev Mengle by Doug Lovell by Dmitry Kirsanov by Chris Von See, Nitin Keskar by Johan Hjelm, Peter Stark SVG (Scalable Vector Graphics) by Andrew H. Watt by Ellen Pearlman, Lorien House by Oswald Campesato by Micah Laaker by J. David Eisenberg by Bill Trippe, et al by Marc Campbell, Jason Cranford Teague by Kurt Cagle by Chris Lilley, et al VoiceXML by Adam Hocek, David Cuddihy by Kenneth R.

Abbott by Dreamtech Software India by James A. Larson by Mark Miller by Chetan Sharma, Jeff Kunins Web development by Michael Floyd by Bill Brogden, Conrad D'Cruz, Mark Gaither by Hiroshi Maruyama by Dave Taylor by Johan Hjelm by Don Gosselin by Don Gosselin by Serge Abiteboul, Dan Suciu, Peter Buneman by Andrew H.

Watt by Kristen L. Garlock, Sherry Piontek by Ellen Pearlman, Lorien House by Vladimir Geroimenko by Randy Tamura by Akmal B. Chaudhri, Mong Li Lee, Jeffrey Xu Yu, Zoe Lacroix, Stephane Bressan by Dan Livingston by Eric Bell, Hao Howard Feng, Edward L.W. Soong, David Zhang, Shijia Sam Zhu by Elizabeth Castro by Craig D. Knuckles, David Yuen by Paul Whitehead, Ernest Friedman-Hill, Emily A. Vander Veer by Patrick Carey, Mary Kemper by John McConnell, Eric Siegel by Chris Auld, Paul Spencer, Jeff Rafter, Jon James, Dave Addey, Oli Gauti Gudmundsson, Allan Kent, Alex Schiell, Inigo Surguy by Larry Lagerstrom by Ellen Pearlman, Eileen Mullin by Laura Lemay, Rafe Colburn by Doug Kaye by William Trippe, Kate Binder, Bill Trippe by J.

Teague, Marc Campbell by Michel Goossens, Sebastian Rahtz, Eitan M. Gurari, Ross Moore, Robert S.

Sutor by Cheryl M. Hughes by IBM Redbooks by IBM Redbooks by Kenneth R. Abbott by Mark Miller by Jeffrey Griffin, Carlos Morales, John Finnegan by Manfred Knobloch, Matthias Kopp by T. Raman by Kurt Cagle, Joseph A. Webb by Brian Proffitt, Ann Zupan by Author Team Glasshaus by Hiroshi Maruyama, Andy Clark, Makoto Murata, Naohiko Uramoto, Kent Tamura, Yuichi Nakamura, Ryo Neyama, Kazuya Kosaka, Satoshi Hada by Daniel Appelquist by Bhavani Thuraisingha by Elizabeth Castro by Kevin Ruse by Adolfo Vazquez Rodriguez by Jack Park, Sam Hunting by Emily A. Vander Veer, Rev Mengle by Erik Wilde, David Lowe by Dmitry Kirsanov Web Services by Anthony T. Mann by Kris Jamsa by Keith Ballinger by Kenn Scribner, Mark Stiver by William L.

Oellermann Jr. By Sean Christofferson, Srinivas Jayanthi, Steven Traut, Wira Pradjinata by Richard Hundhausen, Steven Borg, Cole Francis, Kenneth Wilcox by Lonnie Wall, Andrew Lader by Steve Graham, Simeon Simeonov, Toufic Boubez, Glen Daniels, Doug Davis, Yuichi Nakamura, Ryo Neyama by Scott Short by Daniel A.

Menasce, Virgilio A.F. Almeida by Gregory Brill by Winnie Tang, Jan Selwood by Anura Guruge by Scott Seely, Deon Schaffer, Eric A. Smith by Eric Rosebrock by Clifford Berg by David Jorgensen by Sandeep Chatterjee, James Webber by Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh by Robert Hablutzel by IBM Redbooks by Dougal Watt by Eric A. Marks, Mark J. Werrell by Alexander Nakhimovsky, Tom Myers by Jason Clark (Wintellect) by Alex Nghiem by Michael Yawn by Ray Lai by Pankaj Kumar by Richard Monson-Haefel by Robert Flenner, Michael Abbott, Toufic Boubez, Frank Cohen, Navaneeth Krishnan, Alan Moffet, Rajam Ramamurti, Bilal Siddiqui, Frank Sommers by James McGovern, Sameer Tyagi, Michael Stevens, Sunil Mathew by Harvey M. Deitel, Paul J.

Deitel by Kim Topley by Rashim Mogha, V. Preetham by Robert J. Brunner, Frank Cohen, Francisco Curbera, Darren Govoni, Steven Haines, Matthias Kloppmann, Benoit Marchal, K.

Scott Morrison, Arthur Ryman, Joseph Weber by David A. Chappell, Tyler Jewell by Mike Jasnowski by Casey Kochmer, Erica Frandsen by John Edwards by Doug Kaye by Bret Hartman, Donald J. Flinn, Konstantin Beznosov, Shirley Kawamoto by Kirk Hausman, Ed Tittel by Amit Kalani, Priti Kalani by Microsoft Corporation by Mike Gunderloy by Amit Kalani, Priti Kalani by Kenneth S. Lind by Pamela Fanstill, Helen O'Boyle, Mitch Ruebush, Brian Reisman by Matthew Macdonald by Adam Freeman, Allen Jones by Robert Tabor by John Paul Mueller by David S. Linthicum by John Hagel III, John Seely Brown by John Paul Mueller, Sybex by Alex Ferrara, Matthew Macdonald by Danie Damien, Maharry Foggon by Randy J. Ray, Pavel Kulchenko by James Snell, Doug Tidwell, Pavel Kulchenko by Simon St. Laurent, Edd Dumbill, Joe Johnston by Yasser Shohoud by Mark Augustyniak, Chris Payne by Stephen Potts, Mike Kopack by Jothy Rosenberg, David Remy by Thomas Erl by Eric Armstrong, Stephanie Bodoff, Debbie Carson, Maydene Fisher, Dale Green, Kim Haase by Michael C.

Daconta, Leo J. Obrst, Kevin T.

Smith by Naresh Apte, Toral Mehta by Eric Newcomer by Roger Jennings by Mike Plusch by Douglas K. Barry by Peter Fletcher, Mark Waterhouse, Mike Clark by Peter Darakhvelidze, Eugene Markov by Bill Evjen by Ethan Cerami by Joe Clabby by Brian E. Travis, Mae Ozkan by Paul B.

Monday by Brian Nantz, Peter A. Bromberg by Mark O'Neill by Christoph Bussler, Rick Hull, Sheila McIlraith, Maria E. Orlowska, Barbara Pernici, Jian Yang, L. Manevich by Liang-Jie Zhang, Mario Jeckle by Anne Thomas Manes by Harvey M. Deitel, Paul J. Trees by Anura Guruge by Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju by Brian E.

Travis by Ron Schmelzer, Travis Vandersypen, Jason Bloomberg, Madhu Siddalingaiah, Sam Hunting, Michael Qualls, Chad Darby, David Houlding, Diane Kennedy by Bill Evjen by Chris Boar by Geetanjali Arora, Sai Kishore, Niit by Frank P. Coyle Wireless by Johan Hjelm by Jeff Zhuk by William Routt by Mikael Hillborg by Guy Lotgering, Judy Bass XHTML by Dave Taylor by Don Gosselin by Don Gosselin by John Cowell by Timothy T. Gottleber, Timothy N. Trainor, Johny K. Johansson by James H. Pence by Gary Rebholz by Thomas A. Powell by Chuck Musciano, Bill Kennedy by Elizabeth Castro by Bryan Pfaffenberger, Bill Karow, Chuck White, Steven M.

Schafer by Kelly L. Murdock by Deborah S. Ray by Ibrahim Zeid by Ed Tittel, Chelsea Valentine, Mary Burmeister by Ed Tittel, Chelsea Valentine, Lucinda Dykes, Mary Burmeister by Eric Ladd, Jim O'Donnell, Mike Morgan, Andrew H Watt by Larry Lagerstrom by Dick Oliver, Michael Morrison by Deidre Hayes by Laura Lemay, Rafe Colburn by Molly E. Holzschlag by Molly E. Holzschlag by Jeremy Kurtz, Stephen Morosko by Jeffrey Griffin, Carlos Morales, John Finnegan by William Routt by Kurt Cagle, Joseph A. Webb by Aaron E.

Walsh, Dave Raggett by Brian Proffitt, Ann Zupan by Author Team Glasshaus by Chelsea Valentine, Chris Minnick by Molly E. Holzschlag XML by Michael Young by David Hunter, Kurt Cagle, Chris Dix, Roger Kovack, Jonathan Pinnock, Jeff Rafter by Charles F. Goldfarb, Paul Prescod by Gregory Brill by David Gulbransen.

A while ago, I started on a project where I designed a html-esque XML schema so that authors could write their content (educational course material) in a simplified format which would then be transformed into HTML via XSLT. I played around (struggled) with it for a while and got it to a very basic level but then was too annoyed by the limitations I was encountering (which may well have been limitations of my knowledge) and when I read a blog suggesting to ditch XSLT and just write your own XML-to-whatever parser in your language of choice, I eagerly jumped onto that and it's worked out brilliantly.

I'm still working on it to this day ( I'm actually supposed to be working on it right now, instead of playing on SO), and I am seeing more and more things which make me think that the decision to ditch XSLT was a good one. I know that XSLT has its place, in that it is an accepted standard, and that if everyone is writing their own interpreters, 90% of them will end up on. But given that it is a instead of the procedural style which most programmers are familiar with, for someone embarking on a project such as my own, would you recommend they go down the path that I did, or stick it out with XSLT? Advantages of XSLT: • Domain-specific to XML, so for example no need to quote literal XML in the output.

• Supports XPath/XQuery, which can be a nice way to query DOMs, in the same way that regular expressions can be a nice way to query strings. • Functional language.

Disadvantages of XSLT: • Can be obscenely verbose - you don't have to quote literal XML, which effectively means you do have to quote code. And not in a pretty way. But then again, it's not much worse than your typical SSI. • Doesn't do certain things which most programmers take for granted. For instance string manipulation can be a chore.

This can lead to 'unfortunate moments' when novices design code, then frantically search the web for hints how to implement functions they assumed would just be there and didn't give themselves time to write. • Functional language. One way to get procedural behaviour, by the way, is to chain multiple transforms together. After each step you have a brand new DOM to work on which reflects the changes in that step. Some XSL processors have extensions to effectively do this in one transform, but I forget the details.

So, if your code is mostly output and not much logic, XSLT can be a very neat way to express it. If there is a lot of logic, but mostly of forms which are built in to XSLT (select all elements which look like blah, and for each one output blah), it's likely to be quite a friendly environment.

If you fancy thinking XML-ishly at all times, then give XSLT 2 a go. Otherwise, I'd say that if your favourite programming language has a good DOM implementation supporting XPath and allowing you to build documents in a useful way, then there are few benefits to using XSLT. Bindings to libxml2 and gdome2 should do nicely, and there's no shame in sticking to general-purpose languages you know well.

Home-grown XML parsers are usually either incomplete (in which case you'll come unstuck some day) or else not much smaller than something you could have got off the shelf (in which case you're probably wasting your time), and give you any number of opportunities to introduce severe security issues around malicious input. Don't write one unless you know exactly what you gain by doing it. Which is not to say you can't write a parser for something simpler than XML as your input format, if you don't need everything that XML offers. So much negativity! I've been using XSLT for a good few years now, and genuinely love it.

The key thing you have to realise is that it's not a programming language it's a templating language (and in this respect I find it indescribably superior to asp.net /spit). XML is the de facto data format of web development today, be it config files, raw data or in memory reprsentation. XSLT and XPath give you an enormously powerful and very efficient way to transform that data into any output format you might like, instantly giving you that MVC aspect of separating the presentation from the data. Then there's the utility abilities: washing out namespaces, recognising disparate schema definitions, merging documents.

It must be better to deal with XSLT than developing your own in-house methods. At least XSLT is a standard and something you could hire for, and if it's ever really a problem for your team it's very nature would let you keep most of your team working with just XML. A real world use case: I just wrote an app which handles in-memory XML docs throughout the system, and transforms to JSON, HTML, or XML as requested by the end user. I had a fairly random request to provide as Excel data. A former colleague had done something similar programatically but it required a module of a few class files and that the server had MS Office installed! Turns out Excel has an XSD: new functionality with minimum basecode impact in 3 hours. Personally I think it's one of the cleanest things I've encountered in my career, and I believe all of it's apparent issues (debugging, string manipulation, programming structures) are down to a flawed understanding of the tool.

Obviously, I strongly believe it is 'worth it'. I have to admit a bias here because I teach XSLT for a living. But, it might be worth covering off the areas that I see my students working in. They split into three groups generally: publishing, banking and web.

Many of the answers so far could be summarised as 'it's no good for creating websites' or 'it's nothing like language X'. Many tech folks go through their careers with no exposure to functional/declarative languages.

When I'm teaching, the experienced Java/VB/C/etc folk are the ones who have issues with the language (variables are variables in the sense of algebra not procedural programming for example). That's many of the people answering here - I've never gotten on with Java but I'm not going to bother to critique the language because of that. In many circumstances it is an inappropriate tool for creating websites - a general purpose programming language may be better. I often need to take very large XML documents and present them on the web; XSLT makes that trivial.

The students I see in this space tend to be processing data sets and presenting them on the web. XSLT is certainly not the only applicable tool in this space.

However, many of them are using the DOM to do this and XSLT is certainly less painful. The banking students I see use a DataPower box in general. This is an XML appliance and it's used to sit between services 'speaking' different XML dialects.

Transformation from one XML language to another is almost trivial in XSLT and the number of students attending my courses on this are increasing. The final set of students I see come from a publishing background (like me).

These people tend to have immense documents in XML (believe me, publishing as an industry is getting very into XML - technical publishing has been there for years and trade publishing is getting there now). These documents need to be processing (DocBook to ePub comes to mind here). Someone above commented that scripts tend to be below 60 lines or they become unwieldy. If it does become unwieldy, the odds are the coder hasn't really got the idea - XSLT is a very different mindset from many other languages. If you don't get the mindset it won't work. It's certainly not a dying language (the amount of work I get tells me that).

Right now, it's a bit 'stuck' until Microsoft finish their (very late) implementation of XSLT 2. But it's still there and seems to be going strong from my viewpoint. We use XSLT extensively for things like documentation, and making some complex configuration settings user-serviceable. For documentation, we use a lot of DocBook, which is an XML-based format. This lets us store and manage our documentation with all of our source code, since the files are plain text. With XSLT, we can easily build our own documentation formats, allowing us to both autogenerate the content in a generic way, and make the content more readable.

For example, when we publish release notes, we can create XML that looks something like: Error when clicking the Foo button Crash at startup when configuration is missing Error when clicking the Bar button And then using XSLT (which transforms the above to DocBook) we end up with nice release notes (PDF or HTML usually) where bug IDs are automatically linked to our bug tracker, bugs are grouped by component, and the format of everything is perfectly consistent. And the above XML can be generated automatically by querying our bug tracker for what has changed between versions.

The other place where we have found XSLT to be useful is actually in our core product. Sometimes when interfacing with third-party systems we need to somehow process data in a complex HTML page. Parsing HTML is ugly, so we feed the data through something like (which generates proper SAX XML events, essentially letting us deal with the HTML as if it were properly written XML) and then we can run some XSLT against it, to turn the data into a 'known stable' format that we can actually work with. By separating out that transformation into an XSLT file, that means that if and when the HTML format changes, the application itself does not need to be upgraded, instead the end-user can just edit the XSLT file themselves, or we can e-mail them an updated XSLT file without the entire system needing to be upgraded.

I would say that for web projects, there are better ways to handle the view side than XSLT today, but as a technology there are definitely uses for XSLT. It's not the easiest language in the world to use, but it is definitely not dead, and from my perspective still has lots of good uses. XSLT is an example of a language. Other examples of declarative programming languages include regular expressions, Prolog, and SQL. All of these are highly expressive and compact, and usually very well designed and powerful for the task for which they are designed. However, software developers generally hate such languages, because they are so different from more mainstream OO or procedural languages that they're hard to learn and debug. Their compact nature generally makes it very easy to do a lot of damage inadvertently.

So while XSLT is an efficient mechanism to merge data into presentation, it fails in the ease-of-use department. I believe that's why it hasn't really caught on. XSLT is functional, but I think it's debatable whether it is declarative (there are ordering dependancies etc). However, I agree with your point that this (whether functional or declarative) is both a powerful thing, as well as a source of frustration for most OO/ procedural programmers.

However, in XSLT's case I believe that, as a functional language, it lacks too many of the features that make most functional languages usable. As a result you typically end up writing a lot more code, rather than it being compact. Have you tried splitting strings in XSLT (1.0), for example? – Aug 13 '09 at 7:55 3. I've used XSLT (and also XQuery) extensively for various things - to generate C++ code as part of build process, to produce documentation from doc comments, and within an application that had to work with XML in general and XHTML in particular a lot. The code generator in particular was in excess of 10,000 lines of XSLT 2.0 code spread around about a dozen separate files (it did a lot of things - headers for clients, remoting proxies/stubs, COM wrappers,.NET wrappers, ORM - to name a few).

I inherited it over another guy who didn't really understand the language well, and the older bits were consequently quite a mess. Newer stuff that we wrote was mostly kept sane and readable, however, and I do not recall any particular problems with achieving that. It was certainly not any harder than doing it for C++. Speaking of versions, dealing with XSLT 2.0 definitely helps keep you sane, but 1.0 is still alright for simpler transforms. In its niche, it is an extremely handy tool, and the productivity you get from certain domain-specific features (most importantly, dynamic dispatch via template matching) is hard to match.

Despite the perceived wordiness of XSLT's XML-based syntax, the same thing in LINQ to XML (even in VB with XML literals) was usually several times longer. Quite often, however, it gets undeserved flack because of unnecessary use of XML in some case in the first place. To sum it up: it is an incredibly useful tool to have in one's toolbox, but it is a very specialized one, so it is good so long as you use it properly and for its intended purpose. I really wish there was a proper, native.NET implementation of XSLT 2.0. I use XSLT (for lack of better alternative), but not for presentation, just for transformation: • I write short XSLT transformations to do mass edits on our maven pom.xml files. • I've written a pipeline of transformations to generate XML Schemas from XMI (UML Diagram). It worked for a while, but it finally got too complex and we had to take it out behind the barn.

• I've used transformations to refactor XML Schemas. • I've worked around some limitations in XSLT by using it to generate an XSLT to do the real work. (Ever tried to write an XSLT that produces an output using namespaces that aren't known until runtime?) I keep coming back to it because it does a better job round-tripping the XML it's processing than other approaches I've tried, which have seemed needlessly lossy or simply misunderstand XML. XSLT is unpleasant, but I find using makes it bearable.

That said, I'm investigating using (a lisp) to perform transformations of XML, but I haven't gotten far enough yet to know if that approach will bring me benefits. Personally I used XSLT in a totally different context. The computer game that I was working on at the time used tons of UI pages defined using XML. During a major refactor shortly after a release we wanted to change the structure of these XML documents.

We made the game's input format follow a much better and schema aware structure. XSLT seemed the perfect choice for this translation from old format ->New format. Within two weeks I had a working conversion from old to new for our hundreds of pages. I was also able to use it to extract lots of information on the layout of our UI pages. I created lists of which components were imbedded in which relatively easily which I then used XSLT to write into our schema definitions. Also, coming from a C++ background, it was a very fun and interesting language to master.

Albatron Px865pe Pro Windows 7 Driver. I think that as a tool to translate XML from one format to another it is fantastic. However, it is not the only way to define an algorithm that takes XML as an input and outputs Something. If your algorithm is sufficiently complex, the fact that the input is XML becomes irrelevant to your choice of tool - i.e roll your own in C++ / Python / whatever. Specific to your example, I would imagine the best idea would be to create your own XML->XML convert that follows your business logic. Next, write a XSLT translator that just knows about formatting and does nothing clever. That might be a nice middle ground but it totally depends what you are doing. Having a XSLT translator on the output makes it easier to create alternative output formats - printable, for mobiles, etc.

Yes, I use it a lot. By using different xslt files, I can use the same XML source to create multiple polyglot (X)HTML files (presenting the same data in different ways), a RSS feed, an Atom feed, a RDF descriptor file and fragment of a site map. It's not a panacea. There are things it does well, and things it doesn't do well, and like all other aspects of programming, it's all about using the right tool for the right job. It's a tool that's well worth having in your toolbox but it should used only when it's appropriate to do so.

I have found XSLT to be quite difficult to work with. I have had experience working on a system somewhat similar to the one you describe. My company noted that the data we were returning from 'the middle tier' was in XML, and that the pages were to be rendered in HTML which might as well be XHTML, plus they'd heard that XSL was a standard for transforming between XML formats. So the 'architects' (by which I mean people who think deep design thoughts but apparently never code) decided that our front tier would be implemented by writing XSLT scripts that transformed the data into the XHTML for display. The choice turned out to be disastrous.

XSLT, it turns out, is a pain to write. And so all of our pages were difficult to write and to maintain. We would have done much better to have used JSP (this was in Java) or some similar approach that used one kind of markup (angle brackets) for the output format (the HTML) and another kind of markup (like <%.%>) for the meta-data. The most confusing thing about XSLT is that it is written in XML, and it translates from XML to XML. It is quite difficult to keep all 3 different XML documents straight in one's mind. Your situation is slightly different: instead of authoring each page in XSLT as I did, you only need to write ONE bit of code in XSLT (the code to convert from templates to display). But it sounds like you may have run into the same kind of difficulty that I did.

I would say that trying to interpret a simple XML-based DSL (domain specific language) like you are doing is NOT one of the strong points of XSLT. (Although it CAN do the job. After all, it IS Turing complete!) However, if what you had was simpler: you have data in one XML format and wanted to make simple alterations to it -- not a full page-description DSL, but some simple straightforward modifications, then XSLT is an excellent tool for that purpose. It's declarative (not procedural) nature is actually an advantage for that purpose.

-- Michael Chermside.