TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

XSLT is a failure wrapped in pain

186 点作者 armenb超过 10 年前

32 条评论

grndn超过 10 年前
The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc).<p>I would not be surprised if someone soon announces a &quot;JSON Transformation&quot; tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so you can mix different schemas, a standard for binary JSON, a standard for JSON-encryption, and so on.<p>&quot;Those who cannot remember the past are condemned to repeat it.&quot;
评论 #8709223 未加载
评论 #8709266 未加载
评论 #8709059 未加载
评论 #8709222 未加载
评论 #8709098 未加载
评论 #8709109 未加载
评论 #8709709 未加载
评论 #8709224 未加载
评论 #8709461 未加载
评论 #8709210 未加载
评论 #8709946 未加载
评论 #8709155 未加载
nly超过 10 年前
What&#x27;s with linking to an old &quot;XML sucks&quot; page with no content, insight or original thought? Is it bash &lt;whatever-was-on-the-homepage-a-few-hours-ago&gt; time?<p>On XSLT: find something that fills its role completely, with the same level of tooling, and then have a rant about inferior tools being popular, until then it doesn&#x27;t really matter if it sucks.
评论 #8709273 未加载
VMG超过 10 年前
Since it is the hot topic of the day, let me add this perspective: <a href="http://www.snoyman.com/blog/2012/04/xslt-rant.html" rel="nofollow">http:&#x2F;&#x2F;www.snoyman.com&#x2F;blog&#x2F;2012&#x2F;04&#x2F;xslt-rant.html</a><p>Quote<p><i>&gt; I&#x27;m not even talking about the hideously verbose syntax, or the completely obtuse data model. The fact that you can&#x27;t know what any single line of code does without reviewing every other line in the program makes this language an abomination.</i>
评论 #8709269 未加载
robert_tweed超过 10 年前
One quote sums it up:<p>“XML is simply lisp done wrong.” – Alan Cox<p>It&#x27;s not that XSLT isn&#x27;t useful in some situations. It is. It&#x27;s not that clean, simple and efficient XSLT is impossible. It is, but it&#x27;s hard.<p>The fact that it isn&#x27;t Turing complete can be a good thing. It can also cause a lot of headaches.<p>The main problem is that XSLT as designed and as implemented is an over-engineered god-awful mess. XSLT 2 was a huge improvement, but nobody implemented it, or they maybe only implemented bits of it in nonstandard ways (MSXML), so none of the better parts were reliable.<p>The idea of XSLT was sound and XPATH was pretty nice, but anyone who thinks XSLT is &quot;good&quot; probably has never worked on a large XSLT-based project (one where XSLT files routinely include other XSLT files and XML documents routinely link to other XML documents via xlink).<p>People say complexity gets out of control with OOP. Those issues pale into insignificance compared with rampant pattern matching split over many files when you have dozens of different schemas and are dealing with massive document graphs (with the occasional cyclic edge for good measure).<p>Good luck trying to reliably predict results in advance, or add any sort of control-flow logic to deal with edge cases without resorting to hard-coding and unrolling recursion.
评论 #8709436 未加载
bambax超过 10 年前
Rather than singing the praise of XSLT (which I love) I&#x27;ll show an example: this tool transforms any rich text to markdown:<p><a href="http://markitdown.medusis.com" rel="nofollow">http:&#x2F;&#x2F;markitdown.medusis.com</a><p>It&#x27;s about 30 lines of XSLT that run in the browser. [Edit: it&#x27;s not 30 lines but 230, but I was thinking of the number of &quot;rules&quot; (templates) of which there are only 29.]<p>There are very few other tools of its kind and I don&#x27;t think there exists any client-side, with the same simplicity. This attempt for example<p><a href="https://github.com/domchristie/to-markdown/blob/master/src/to-markdown.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;domchristie&#x2F;to-markdown&#x2F;blob&#x2F;master&#x2F;src&#x2F;t...</a><p>is about 180 lines of JS, is incomplete, doesn&#x27;t work with many special cases, etc.<p>There is no better templating language than XSLT; every other templating approach (in PHP or Python on the server, in JavaScript on the client) feels like a horrible kludge once you&#x27;ve experienced XSLT.<p>Yes, XSLT is practically dead, that&#x27;s a fact. But we should be very sad about it, instead of dancing on the coffin like the OP with its stupid quotes.
评论 #8708734 未加载
评论 #8708716 未加载
评论 #8708720 未加载
geonik超过 10 年前
Those who rant about XML and XSLT know nothing about what they talk about. 50% of our server&#x27;s behavior (200,000 Java LOCs) is orchestrated declaratively by a small number of XML files that use around 30 custom namespaces. These are<p>1. parsed on server startup for setting up persistence, business rules, REST endpoints etc<p>2. transformed by XSLT to a) produce nice HTML documentation, including DOT class diagrams b) generate Java source code c) validate declaration integrity and cross-referencing<p>With the right XSDs, IDE support is excellent (auto complete for everything). Take the time to learn it, apply it according to your needs, and reap the benefits- in the long run, maintenance work is down by an order of magnitude.
评论 #8708858 未加载
sly010超过 10 年前
I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem.<p>I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny, not objective. Noone actually brought an objective facts against XML. Because they can&#x27;t. The fact is it is widely used in many places. Anyone tell me an alternative to serialise an object tree where you also need to preserve ordering and type information, you need to store text longer than one line, or you just need to store any kind of formatting information. (and yes, you can use JSON to do that, but the resulting document will be 5x longer)<p>(meta: Funny quotes bashing useful technologies is the cat video equivalent of HN. Last week&#x27;s article beating OOP was the same pattern.)
评论 #8709233 未加载
评论 #8709227 未加载
评论 #8709229 未加载
gioele超过 10 年前
How many languages can tell you that byte X of output has been generated from byte Y of input going though such and such steps?<p>When programming in XSLT it is great to fire up a debugger (let&#x27;s say oXygen), run your transformation, click on the wrong output and being able to go step-by-step <i>backwards</i>.<p>How many languages designed before 1999 (yeah, XSLT is 15 years old) can claim to be able to do so?
评论 #8709476 未加载
评论 #8709333 未加载
dexen超过 10 年前
Also the venerable, tongue-in-cheek, &quot;Not the comp.text.sgml FAQ&quot; [1] by Joe English.<p>Sample:<p><pre><code> Q. I&#x27;m designing my first DTD. Should I use elements or attributes to store data? A. Of course. What else would you use? </code></pre> [1] <a href="http://www.flightlab.com/~joe/sgml/faq-not.txt" rel="nofollow">http:&#x2F;&#x2F;www.flightlab.com&#x2F;~joe&#x2F;sgml&#x2F;faq-not.txt</a>
krab超过 10 年前
The point with namespaces leads me to think that the main problem with XML is that on the surface it looks very simple but in fact it&#x27;s not. It is tempting to take shortcuts to process the XML: for example parsing with regexes, looking at the namespace prefix and not at its definition, producing XML without proper escaping. There are also some gotchas like certain characters being non-representable in XML.<p>I personally like XML and XSLT (2.0) but to be able to work efficiently you need to spend some time learning which is not obvious on the first sight.<p>What about the alternatives?<p>JSON has a big advantage which is its unambiguous automapping to objects. This benefit is not that apparent in languages like Java where you&#x27;d still declare a class to represent either the XML or the JSON document. Moreover, there are projects which essentially try to bring schema and namespaces to JSON. JSON-LD is an example of a namespace without an explicit support in the underlying format. There is even a command-line tool jq big part of which is an engine similar to XPath.<p>S-expressions if used widely would probably go the same path as JSON - recreating a lot of what is considered as bloat in XML.<p>Another mentioned alternative was a custom text format. I assume the author meant just to design a format from scratch. I wrote that to use XML efficiently, you need to put in some work. But compared to making a backwards (and forwards?) compatible text format which correctly handles malformed and malicious input requires much more effort.<p>I don&#x27;t know anything about ndb.
ilitirit超过 10 年前
XSLT does indeed have implementation issues, but it really is very powerful once you know how to use it properly. And I don&#x27;t get how it&#x27;s a &quot;failure&quot;. It&#x27;s one of the most widely used technlogies in the publishing industry.<p>Our company once had an application that processed the end-of-year high school student results and then published them in various newspapers. The input files were text files generated from the Education Department&#x27;s database from various regions. The process took around 10-15 minutes (lot&#x27;s of rules had to be run against the data). I replaced it with a Windows JScript script and XSLT. It took 15 seconds to transform the data.<p>That said, I still use XSLT regularly but I&#x27;d be lying if I enjoyed working with it. Using a decent IDE for development and debugging can help.<p>Someone did give me a nice tip for working with and learning XLST though - &quot;translate your transformation rules directly from simple English to the template rules&quot;.<p>eg. &quot;I need to insert the node &lt;member&gt; under &lt;group&gt;&quot;<p><pre><code> &lt;xsl:template match=&quot;group&quot;&gt; &lt;group&gt; &lt;member&#x2F;&gt; &lt;xsl:apply-templates&#x2F;&gt; &lt;&#x2F;group&gt; &lt;&#x2F;xsl:template&gt; </code></pre> &quot;But if the group node exist, doesn&#x27;t create, then create it&quot;<p><pre><code> &lt;xsl:template match=&quot;root[not(group)]&quot;&gt; &lt;root&gt; &lt;group&gt; &lt;member&#x2F;&gt; &lt;&#x2F;group&gt; &lt;xsl:apply-templates&#x2F;&gt; &lt;&#x2F;root&gt; &lt;&#x2F;xsl:template&gt;</code></pre>
radicalbyte超过 10 年前
The problem with XSLT, XML, SOAP, WS-* is that the community is driven by vendors with deep pockets who use their power to kill interoperability.<p>Imagine LISP, but in the hands of Sauron or Palpatine. That&#x27;s the XML group of technology.
评论 #8708810 未加载
paulsutter超过 10 年前
JSON&#x2F;Javascript is just easier to learn and work with than XML&#x2F;XSLT. For starters, you don&#x27;t need to learn a special language that you&#x27;ll never use for anything else.<p>Just in case you &#x2F;do&#x2F; need to use XML every day: the primary benefit of XSLT is that it lets you avoid using XML libraries to munge some XML. Because the XML libraries are so horrendous to use from any language.
评论 #8708737 未加载
评论 #8708995 未加载
rwallace超过 10 年前
The first part of the first quote is incorrect. The problem XML solved was bloody hard, though most people nowadays have forgotten what it was. It was to get the world&#x27;s programmers to stop creating binary file formats, to put an end to the situation where every time you went onto a site, the first thing you had to do was reverse engineer binary files with a hex dump utility. XML, to its very great credit, solved that problem.<p>Now if you want to start asking whether it solves the problem as well as today&#x27;s competing technologies like JSON, at that point I will step back and hold my peace.
bibonix超过 10 年前
XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don&#x27;t understand it and that&#x27;s why can&#x27;t use it, should just do their home work and learn better
评论 #8709264 未加载
评论 #8708704 未加载
评论 #8708712 未加载
duncanawoods超过 10 年前
I believe the fundamental pain of xslt was... that it was an FP language. When teaching XSLT, the difference between those who said &quot;its elegant&quot; vs. those who said &quot;its pain&quot; - is whether the individual could grok FP.<p>Angle bracket overload, verbosity of end tags, library support, poor whitespace handling, namespace pain were all obstacles too but it was FP that made standard problems feel like math proofs and for developers to take days to solve problems they could code in minutes in their usual OO&#x2F;imperative language.<p>When I see the pain FP causes in the real world I&#x27;m never quite sure whether its nature or nurture. I currently believe its a bit of both but the nature part will always hobble FP adoption - if you find algebraic proofs elegant, you will like FP. If you are &quot;normal&quot; and proving a theorem fills you with terror then you would prefer your programming language to resemble a a cookery recipe.<p>I also believe all templating, especially for code-generation, requires three brains - understanding the input data-structure, understanding the processing of the template and understanding the behaviour of the output. Each keystroke in your templating language has to be carried out with full understanding of all three parts. Its too much for those if they still struggle with more common two brain programming problems.
评论 #8708826 未加载
评论 #8708814 未加载
评论 #8708804 未加载
评论 #8708872 未加载
评论 #8709064 未加载
kabdib超过 10 年前
I once worked on an embedded system with not a lot of RAM or code space, and we were ripping features out to put new stuff in and rewriting things to make new things fit (not a bad practice, re-writing, btw). I wrote some tools to do global optimization at the assembly language level and got back 40K because our compiler was one of those $5000 &#x2F; seat pieces of crap, and we didn&#x27;t have a debugger, so object-to-source-line mapping, who needs it?<p>Anyway, one of the PMs on the project insisted that this choice little hunk&#x27;O&#x27;hell communicate with the outside world -- at about 2K bits &#x2F; sec on a good day -- using XML. Because it was standard. Because XML added to anything makes it better, no matter what it is. Because, well, nobody ever saw that traffic except other computers, but XML!<p>I wanted to kill, kill, kill, but instead I wrote an XML parser (kind of) that fit into about 1K of code. &quot;Don&#x27;t use entities or CDATA or namespaces,&quot; I said, and went away to a better place. I think the PM was happy. That group got sold to a company famous for its 60s-era radios and crappy teevees, and I assume everyone is happy there, because I have not heard a word from them, and XML!
chinpokomon超过 10 年前
I&#x27;ve seen XSLT done well, and I&#x27;ve seen the mess it can be when written by someone with only a passing knowledge. As a consultant I usually have dealt with the latter, and that usually goes hand in hand with a poorly designed XML schema.<p>One space that XSLT can demonstrate its strength is when transforming some horribly serialized interoperability data structure. If the system from which you are receiving data, produces terse XML, you aren&#x27;t going to solve anything by rewriting the upstream system to produce equally lousy JSON. If you don&#x27;t have the ability to fix the upstream service to produce better structured data, XSLT and XPath are wonderful tools to morph it into something more manageable. That transformation process is better written with XSLTs than it is in trying to do the same thing by slurping the data directly into some business object and trying then to work with a bad model. Don&#x27;t go down the path of &quot;garbage out, garbage in.&quot;<p>If you have access to both sides of the process, it might be worth rewriting the upstream system, but when working with a legacy system XSLT might be the best glue technology in your arsenal.
ohyesyodo超过 10 年前
Okay, so what am I supposed to use if I want to transform a XML file from one format to another because two different systems needs XML for input &#x2F;output and they have different fixed formats?
评论 #8708944 未加载
评论 #8708960 未加载
snarfy超过 10 年前
I like this one:<p>&gt;“XML combines the efficiency of text files with the readability of binary files”<p>One dirty thing about XML is that it appears human readable, but it is not human writable. You&#x27;ll see something in the XML that you think you can change, but now it doesn&#x27;t validate anymore after you change it using a text editor. You need an XML editor that understands XML validation to make edits. If I cannot use a basic text editor, it&#x27;s not basic text. If it&#x27;s not basic text, it&#x27;s no better than any other binary protocol, albeit a very inefficient one.
评论 #8710096 未加载
hokkos超过 10 年前
What article are we supposed to look at ? It is witty quotes and links, there in no substance is this article, just bashing. Is it supposed to be an answer to this article that had a lot of discussion on proggit ? <a href="http://www.reddit.com/r/programming/comments/2o5nvy/why_i_like_xslt/" rel="nofollow">http:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;2o5nvy&#x2F;why_i_li...</a>
评论 #8708967 未加载
brokentone超过 10 年前
Reminds me of the person (people, team, etc) who decided it was a good idea to code websites in XML + XSLT. Because XHTML is just not good enough. The most prominent of these (I&#x27;m shocked it&#x27;s still this way) is <a href="http://www.skechers.com/" rel="nofollow">http:&#x2F;&#x2F;www.skechers.com&#x2F;</a>
评论 #8710726 未加载
pm24601超过 10 年前
The problem with most tools is that they go through the &quot;bright and shiny&quot; stage:<p><pre><code> &quot;New tool - cool! Lets use it on EVERY problem.&quot; </code></pre> And are thus misused.<p>XSLT exists for inter-organizational data transfer and transformation. Don&#x27;t use it for any other situation.<p>XML is a good (not perfect) persistent data storage mechanism where you need the data to outlast the program that created it.<p>I go into more explanation here: <a href="http://sworddance.com/blog/2014/12/06/xml-is-not-bad-just-misused/" rel="nofollow">http:&#x2F;&#x2F;sworddance.com&#x2F;blog&#x2F;2014&#x2F;12&#x2F;06&#x2F;xml-is-not-bad-just-mi...</a><p>Lets not blame a tool that was misused.
considerjoost超过 10 年前
If you ever find yourself somewhere you have to work with XML data and the people there use things like XSLT (and suicide is not an option) you should consider using Joost. Joost implements the lesser known STX language. It&#x27;s a far cry from Haskell or other better tools but nonetheless more useful and practical than XSLT for tasks like cleaning and extracting interesting things from blobs of XML. It&#x27;s available here: <a href="http://joost.sourceforge.net" rel="nofollow">http:&#x2F;&#x2F;joost.sourceforge.net</a>
mqsiuser超过 10 年前
Software hackers will come up with a single right solution. This solution is cemented in theory. Transforming one (message) tree into another <i>must</i> be done in the following way: <a href="http://www.usethetree.com" rel="nofollow">http:&#x2F;&#x2F;www.usethetree.com</a><p>Don&#x27;t just downvote me. Challenge me!<p>Edit: Maybe downvote &amp; challenge me :-) ?
cenazoic超过 10 年前
Anyone tried the &quot;XSLT-powered open source content management system&quot;, <a href="http://www.getsymphony.com/" rel="nofollow">http:&#x2F;&#x2F;www.getsymphony.com&#x2F;</a>?
评论 #8709491 未加载
评论 #8709498 未加载
jules超过 10 年前
The syntax of XSLT is obviously godawful, but the architecture was sound.
icantthinkofone超过 10 年前
I think I should collect a bunch of quotes espousing the virtues of XML and XSLT and put them on a web site so people can link to them.
lafar6502超过 10 年前
xml is technically a superset of JSON, just can&#x27;t imagine any clear advantage of JSON vs XML - it&#x27;s the same league, just some minor syntactic differences. And what is the end of the story for JSON, is just a beginning in XML: the concept of namespaces is powerful and totally foreign to JSON. Then XML Schema - another job well done and poorly mimicked in some JSON libraries. XSLT just builds on these concepts and is not a general purpose tool - don&#x27;t see a reason to have strong opinion about something so narrowly specialized.
Mikhail_Edoshin超过 10 年前
I really don&#x27;t understand how programmers can hate XSLT (and XML for that matter). It&#x27;s a marvelous piece of technology, truly. Maybe the whole stack is so ahead of its time that nobody gets it?
miohtama超过 10 年前
XSLT is 15 years old technology. If it is painful or not should be obvious today even before starting a project.
tete超过 10 年前
cat-v is actually pretty nice. A lot of their stuff looks a bit like &quot;Oh my god, why&quot; and &quot;That person just doesn&#x27;t have a clue&quot;. I thought the same with so many technologies that I got into. I always thought KISS was nice and I always felt like abstraction is a good way to reach that KISS.<p>Turns out it is not. Things can fail, really badly even and they do fail, really often even, even when there are companies with big pockets standing behind it and then good luck debugging the mess. This is true even for really proven technologies, but might be less obvious on those.<p>At some point when you are good at some technology, even if it&#x27;s really popular, mainstream, be it some big SQL database (yes, all of PG, SQLite and MySQL even though I love some of those), C, C++, Java, C# or Python&#x2F;Ruby&#x2F;Perl&#x2F;Node.js you will constantly end up with the implementation of the underlying technology.<p>I am not saying XSLT or any of the above don&#x27;t have their use cases, but actually that a lot of them are over-engineered. Using most of these technologies I know there are issues, send bug reports and patches and hey, things get fixed really quickly. That&#x27;s all good and you never can fully avoid these things, but the more simpler you get the less there is that end up biting you and causing you to start out with lets say you having your SASS to CSS compiler having an issue, digging deeper through every library finding a GCC bug or whatever. Such things happen.. more often than one would think. So based on developer pay and the issues it causes (often being a blocker for a whole team) that&#x27;s actually a really big problem.
评论 #8709271 未加载