Hacker News Reader

Comment by stickfigure | Hacker News Reader

It's really too bad that XML+XSLT didn't take off as the "replacement" for HTML. Before you recoil in horror hear me out...

Web pages are a giant mess of content and presentation, and CSS doesn't really help much. XML is at least a way of describing data in a meaningful way. <book>, <author>, <chapter>, etc. XSLT provided a way of formatting XML in the browser. Sure the internet would still be full of inconsistent content structures, but it would still be way easier to machine read than the big mess of arbitrary <div>s and <p>s (most of which just display something blinky) that we have today.

View on HN

The two problems here are that XML/XSLT are horrible to work with (to the extent that you want to achieve what they were supposed to, you do it with the modern "single page app" style where you write javascript that retrieves data from an API and renders it into a UI) and that no-one actually wants to separate the content from the presentation anyway.

Except you just contradicted yourself. If everyone wants to use JavaScript frameworks and APIs for data they they ARE separating the content from the presentation.

If you think JS frameworks are used only for data manipulation, you're sorely mistaken. Runtime styling has been a primary aim of JavaScript code since even before the popularization of jQuery.

> If everyone wants to use JavaScript frameworks and APIs for data they they ARE separating the content from the presentation.

That's not true. The DOM that the javascript frameworks mangle around isn't data but UI elements, some of which happen to be data.

> no-one actually wants to separate the content from the presentation anyway.

Except of course the developers who are using react & friends because it allows them to separate content(data) from presentation(view).

Every time I am forced to work with XML, I wonder how differently it would have turned out had 10% of the resources devoted to building increasingly complex and tangled specs had been instead directed towards making tools and documentation which aren’t terrible. Little things like the user-hostile APIs for namespaces, validation, extension, etc. and often horrible error messages, not to mention the lack of updates for common open source libraries like libxml2 really cemented the XML=pain reputation by the time JSON came along.

I worked in a web app that used XSLT transformations of XML-formatted domain models to render HTML pages. You ended up doing the same sort of thing that React does, but with _far_ more cumbersome programming constructs. Functions done in XSLT were a nightmare.

The idea behind the whole thing was that the "web devs" could be hired for their HTML/CSS skills and never have to touch code. The reality was, they had to become experts in a peculiar, clunky, XSLT-based programming language of their own.

> Functions done in XSLT were a nightmare.

Did you "push" or did you "pull"?

> Did you "push" or did you "pull"?

I think you're proving my point. :-)

More specifically, we defined parameterized components that could be composed to form the output. The definition of those components was incredibly verbose, as was the instantiation, and it was tightly coupled to parts of the domain model in surprising ways. IIRC WebDevs ended up having to work a step removed from the final XSLT, using some DSL for components that transformed down to XSLT.

Further, deponent sayeth not.

I would love to see, what you did there, because, from your description, I do not understand, why you needed to use some DSL, if your input was XML and your output should have been XML, too.

And how does my question prove your point?

I am asking, because I really would like to understand, what happened there.

My gripe with JSON winning is that we're left with competing standards for JSON paths, transformation, and JSON Schema is still a draft. Clunky as XML is, the tooling is more portable and powerful.

That probably would have been cleaner back in the day, but with rich UIs being what they are, I think JSON + client side templating logic is probably simpler (and composes well).

I never had much luck using XSLT for anything non-trivial, and I imagine that experience isn't uncommon.

This only addresses the easiest and least interesting problem to solve if it’s really a problem at all (I mean this doesn’t even show up on the Doctorow list of “meta crap” as an issue— like micro formats are ugly but they can do essentially the same thing). It just makes peoples lives miserable to use more XML for no benefit.

> XSLT provided a way of formatting XML in the browser.

Actually, that was XSL:FO.

XSLT is transformation, not formatting; of course you could translate to (X)HTML with embedded styles, or XSL:FO or something else that includes formatting, but XSLT doesn't do formatting itself.

No, XSL-FO does not do formatting in the browser. It is meant to do printed page formatting. Currently the most common drivers produce PDF. But I heard, there is a LaTeX driver as well as PS.

Typical workflow is: XML -> XSL-T -> XSL-FO

The thing that makes this hard is the security model in browsers. You either keep the XSLT scripts in the same directory as the XML or need to turn off the check for cross-site scripts.

Ok, how do you get XSLT that isn't in the same directory as XML to work in a browser ?

Reply on news.ycombinator.com