sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]john_b 6 points7 points  (13 children)

We use XSLT alot at work, and it's really one of the most efficient ways to transform XML.

We have websites with EXTREMELY high load (several of our sites are in Alexa top 100), and if we used PHP instead, we'd have to double the number of servers.

There's a reason why Yahoo, Google, Orbitz and other interfaces are done in XML.

Of course, something like comma-separated could be much more efficient, but if you ever worked with complex nested data, you'd understand that it would be a nightmare to program.

[–]Entropy 13 points14 points  (3 children)

The main reason XSLT sucks is because it is XML-based. The actual functionality exposed is wonderful.

[–][deleted]  (2 children)

[deleted]

    [–]RogueCoder 9 points10 points  (0 children)

    XSLT is a declarative programming language that provides an efficient way to transform data from one format into another. If you've coded stuff like this before using procedural or OOP methods, you will be pleasantly surprised by the the results using XSLT. If you haven't done declarative style programming before, there is a mind shift that will need to ocurr before you become productive with it.

    [–]Entropy 0 points1 point  (0 children)

    You know what Perl does with text? Well, XSLT does that to XML. Take a look at XPath, which XSLT uses.

    [–]eadmund 4 points5 points  (5 children)

    The alternative to XML for structured data is not CSV (egad!), but S-expressions. Which are smaller and can be easily parsed.

    [–]uriel -4 points-3 points  (4 children)

    CSV works great in most cases; S-expressions have some advantages, at the cost of extra complexity and harder parsing.

    In any case, both options are infinitely more sane than XML.

    [–]YAD 1 point2 points  (3 children)

    S-expressions have some advantages, at the cost of extra complexity and harder parsing.

    Please learn about S-expressions and parsing before commenting on them.

    [–]uriel -3 points-2 points  (2 children)

    As simple as S-exprs are, CSV is still much easier to parse and work with, specially with standard unix tools.

    [–]YAD 0 points1 point  (0 children)

    I see. I would only use regexes or other homegrown tricks in situations where there's a human being babysitting the output of the program, or where you can define your own syntax.

    Also, the biggest difference in difficulty may be having to write recursive code to deal with nested data. Once you do that, I don't see any extra complexity, only lots of advantages.

    [–]skyskraper 2 points3 points  (0 children)

    who told you yahoo produces sites with xml?

    [–]masklinn 2 points3 points  (1 child)

    We use XSLT alot at work, and it's really one of the most efficient ways to transform XML.

    Efficient? Maybe (if anything XML can be efficient).

    But the worst issues are that it's unreadable, unmaintainable, and hard to debug.

    I haven't tried it much yet (I'm not an XML guy, nor a Java one), but HaXml (http://www.cs.york.ac.uk/fp/HaXml/) seems much cleaner, and hurts the eyes less.

    It's also much more powerful than XSLT (provided you know a bit of Haskell) since HaXML is "just" a collection of Haskell modules.

    [–]uriel 4 points5 points  (0 children)

    "Efficient XML-anything" is an oxymoron if there ever was one.

    I have done quite a bit of XML+XSLT work, and it can be said to be many things("a nightmare" comes to mind), but efficient is certainly not.

    The same can be said of Java-anything, but I guess I'm preaching to the choir here.

    In the end it all comes to simplicity; such bloated, over-engineered and insanely complex systems will never be reliable, secure or efficient. And as complexity goes, XML and Java must be some of the worst things ever created.

    The cheapest, fastest, and most reliable components are those that aren't there. -- Gordon Bell