• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

Why XSLT?

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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"
 
Vlad Patryshev
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Vlad Patryshev
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, now I see. It is a different area, document management, not much of programming - in a sense, similar to SQL. Thank you!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!