The use of XSLT (XML Stylesheet Language Transform) has never seen the same popularity of many of the other languages that came out during the internet boom. While it is in use, and in some cases by large successful companies (i.e. Blizzard Entertainment), it has never seemed to reach mainstream. Why do you think this is?
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
回答1:
One problem is that XSLT looks complicated. Any developer should be able to pick up the language constructs as there are analogs in most other languages. The problem is that the constructs and data all look exactly the same which makes it difficult to distinguish between the two which makes XSLT more difficult to read than other languges.
A second issue is that the uses for it are more limited than other languages. XSLT is great at what it does; making complicated or radical transformations on XML. But it doesn't apply to as wide a range of problems as other languages, so it is not used as much.
Third, many programming languages have their own libraries for transforming XML. Much of the time when working with XML, only small changes or lookups are needed. The XML is also probably being generated or consumed by a program the developer is already writing in another language. These factors mean that using a language's built in utilities is just more convenient.
Another problem that all of these issues contribute to is inertia. That is, people don't know it, they don't see that they have much need for it, so they avoid it as a solution if there is another option.
What you end up with is a language that is the last choice of many developers when creating solutions. It is likely that XSLT is even avoided when it would be the best tool for the job as a result.
回答2:
XSLTs uses functional programming - something most programmers are not used to (hence why some people consider it non-intuitive I guess).
回答3:
In my opinion, one of the most annoying things in standard XSLT (I'm talking about XSLT 1.0 because that's the only version I have used) is that it lacked support of string transformations and some basic date-time functions manipulations.
One thing I could never understand is why a function such as translate() was designed and implemented into xpath wheras other more useful functions such as replace, to_lower, to_upper, or - let's be crazy - regular expressions were not.
Some of these issues were adressed I guess with eXSLT (extended xslt ?) for parsers other than Microsoft's MSXML. I say I guess because I actually never used it as it was declared incompatible with MSXML.
I don't understand why XSLT 1.0 was designed with this principle that 'text' manipulation was not be in the scope of the language when it's obvious that whenever you are converting files you can't avoid those string conversion issues (e.g. : transform an unregularly padded date given in french format to american format, 31/1/2008 to 2008-01-31) huh...
These text manipulation issues were generally very basic and easily adressed in MSXML by allowing XSL to be extended with JScript functions : you could call a JScript function to perform some processing just as you would call any XSL template, but I always found that solution inelegant and ended up creating my own XSL template libraries. First because the JScript way broke your XSL portability, and then because it forced you to mix your programming logic : some bits in pure XPath/XSLT expression and other bits in DOM/object notation with JScript.
Not having updatable variables is another limitation that is very confusing for newcomers, some people just don't overcome this and keep struggling with that. In some simple cases you can have workarounds with a mix of paremetrized templates and recursive calls (for example to implement an increasing or decrasing counter) but let's face it, recursion is not that natural.
I think I heard all those limitations were adressed in the XSLT 2.0 specification, sadly MS decided not to implement it and promote XQuery instead. That's sad, why not implement both of them? I think that XSLT would still have a good chance of becoming as popular as CSS became for HTML. When you think about it, the most difficult part in learning XSLT is XPath, the rest is not as difficult as understanding the cascading behaviour in CSS, and CSS has become so popular...
So, in my opinon, it's the lack of all those little things mentioned here and the time it took to adress them in XSLT 2.0 (with not even MS supporting it anyway) that has lead to this situation of impopularity. How I wish MS decided to implement it after all...
回答4:
Because most XSLT implementations have a high memory footprint (I suppose that's caused by the design of the language), because people tended to abuse XSLT for all kinds of things that it was not particularly well-suited for and the purely-declarative nature of XSL which makes certain types of transformations quite difficult.
回答5:
It's great for xml, but not great for typical coding. It lacks typical basic concepts (ie mutable variables) and makes what should be simple quite complex (or impossible). Most of its problems stem from the fact that xml is a great data representation language but not a great programming language. That being said, I use it daily and would recommend it where it makes sense. In conjunction with external namespaces, it can be made more useful (calls to java, etc). In the end, it's another language to learn, and many coders would prefer to stick with something they're used to or resembles something they're used to.
回答6:
Because it is easier to write and maintain code that uses Java, C#, JavaScript, etc. to deserialize an XML stream, transform it, and export the desired output, and XSLT offers no substantial performance advantage.
XSLT makes somethings easy, but it makes other things very, very hard.
回答7:
Well... Maybe because it is a pain to write xslts... I had to write a few xslts a few months ago and I was dreaming of pointy brackets...
<Really> <No> <fun/> </No> </Really> (I do know, that this is no xslt)
回答8:
Generally, the times when you will be required to transform XML data into a different form of XML data, but not do any other processing to it are going to be very limited. Usually XML is used as an intermediary between two separate systems, one of which is usually custom made to process the output of the other. As such it's simpler to just write one of the systems to process the XML output of the other without the extra step of having to perform some kind of transform.
回答9:
XSL is mainstream and widely adopted. What other languages are you referring to? XSL isn't a programming language, just a transformation language, so it is pretty limited in scope.
回答10:
I think it boils down to XML syntax is arguably good for describing data, but it's not a great syntax for what's essentially a programming language (XSLT).
回答11:
As previously stated XSLT (like “the good parts” of JavaScript) is a functional programming language. Most traditional programmers hate this statelessness. Also too many traditional programmers hate angle brackets.
But, most importantly, correct use of XSLT solves both the declarative-GUI-generation and the data-binding problem for the Web server in a platform agnostic way. Vendors like Microsoft are not motivated to celebrate this “inconvenient” power.
However, I will argue that Microsoft has the finest XSLT support for the IDE (Visual Studio) in the world.
回答12:
I think it tried to cover way too many use cases thus becoming a Turing-complete (or so I heard) language. If you try to do any nontrivial transformation, you end up writing complex loops, conditions... in an ugly and verbose language, which is best done with a GPL.
In my view, this complexity makes writing a correct implementation of XSLT difficult and limited the available choices, thus, widespread use among the vocal hackers who often likes to tinker with small and efficient code, not enterprisey code.
回答13:
XSLT is very powerful, but requires a different way of thinking about the problem. It also made life hard for itself by not providing useful data functionality in the early versions. Take for example a ToUpper() style method, you typically implement it with something like:
<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable> <xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable> <xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/> Not the easiest way of coding!
回答14:
xslt is great for xml to xml, when you have data that is already escaped and a clear definition of inputs and outputs. using it for things like xml2html to me just seems like such a headache, and with nearly any dynamic language and css the output is a lot easier to implement with style.
回答15:
I found it great for 'composite web service architecture'.Sometimes number of webservices work together to have the final output.When those webservices need to communicate among them via XML then XSLT can transform the xml message from one form to another.