Guys, I've been wondering for a long time now, why, having Java environment available, and as handy a tool as JSP, why does anyone bother to write document processing in this new artificial language, XSLT? Do not we already have a language, together with the ability to produce any output, and also with the access to all the (relative) richness of Java environment? Is not it kind of odd?
You can use JAXP, SAX or DOM API's instead of XSLT for XML transformations, but you have to actually choose what's better for your application, from architecture and infastracture standpoints. I'm not very good at feasibility studies, but I think we need variations at this point, we cannot have everything standartized. --Alex
With XML gaining wider industry support, it might prove a redundant effort to write your own document processing engine. Eventhough it is not impossible to write a Java program that say, more efficiently processes your XML( than an XSLT engine, ) it is going to be extremely challenging to keep your code in compliance with evolving standards - especially if you have to process documents from an external source.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Ha! It's interesting, how our background affects our perceptions... I like XSLT, because it is a high-level language that liberates me from implementation details. I started as a programmer with SQL and later migrated to more "traditional" procedural language (Clarion, if it says you anything ) With SQL I could make trivial file updates by writing a couple of operators. With Clarion every primitive file union/projection required writing a program, opening files, specifying algorithm, buffers management and so on... And of course, every time I had to check if my program works correct. With SQL I could be sure that as long as I clearly expressed what I want, everything worked correctly. Low-level details were hidden from me and in most cases it was fine. Only if you need something damn complex or horrible effective, you should go down to low-level details and specify not WHAT you want, but HOW you want it to be done. IMHO, XML tremendously lacks two things: 1) a high-level (declarative) language to query information 2) a high-level (declarative) language to modify document structure Currently XSLT serves both proposals plus it supports formatting of the output as well. There are a lot of alternative candidates for "language #1" and "language #2" position If to consider XML's highly amorphous nature and its support for hierarchical structures, it becomes obvious that such languages are not going to be simple. And due to their declarative nature, they will look different from procedural languages. I guess this is what you reffer to as "artificial language"
See, I actually do not consider XML as a language at all. For me, it is a universal data format. So, I do not see any point why XML itself should contain transformation or query instructions. On the other hand, XML is so comfortable to handle that I would propose this format for program files for all (probably future) programming languages. But choosing XML as a representation format for a programming language does not mean the programming language is XML, no. It is easy to imagine how a Java program structure could be easily formated in XML, but this does not turn Java into XML. What I would like to say, though, is that introducing ad-hoc constructs specifically designed to handle elements of XML data is probably no necessary if we can use already existing languages. JSP is a great example. Probably is the problem was just to convert some XML structure to other XML structure, it would make sense to have specific XML transformation language. But why do we need to do just this transformation? Is there a real problem in the real world that would consist of just turning one XML file to another? I cannot imagine such a problem. I may be missing something.
There are actually a huge amount of uses for XML-to-XML and XML-to-XMLish transformations. Even if we ignore the very popular use of XML-to-HTML transformation for web site and document styling, there are still lots of uses. The key thing to remember is that an XML document should contain the absolute minimum information to specify its content, with no extraneous markup or presentation information. To use that core content in any other way, it needs to be transformed; here are just a few examples:
Using XSL:FO to present XML information as marked-up PDF or rtf
Using XSLT to convert (say) numeric data into a graphical form expressed as SVG
Converting between similar but not identical business domain DTDs
Converting from the simplistinc XML produced by a database, to a more application-specific markup