Hacker News new | past | comments | ask | show | jobs | submit login

But who defines the line between "transform" and "arbitrary processing"? One language's transformation is another language's arbitrary processing. If XSLT doesn't know how to format dates for Eskimos, and I have an off-the-shelf JavaScript or .NET date formatting library that does, how does that make my requirements cross the line between "transformation" and "arbitrary processing"? It's a failure of XSLT to not offer Eskimo dates as a transformation (or a way to call a library that does that), not of me for requiring an Eskimo date transformation.

DSSSL was extensible in Scheme, so all transforms had access to arbitrary processing, by the standard.

XSLT was not extensible in any language, so Microsoft went ahead and made a non-standard extension that integrated JavaScript, Visual Basic, C#, and all other IScriptingEngine/.NET compatible languages, much in the same way standard HTML web browsers like Internet Explorer integrate scripting languages.

"The languages that you can use differ between the MSXML and .NET implementations. In MSXML (from version 2.0 on), you can use either VBScript or JavaScript. In .NET, however, you can use any .NET-supported language including C#, Visual Basic, JScript.NET, and even JScript, as before. The ability to use strongly typed languages like C# and Visual Basic .NET makes this an even more attractive opportunity." https://msdn.microsoft.com/en-us/library/bb986124.aspx

Lots of people got lots of work done with Microsoft's non-standard scriptable XSLT, because they believed it was just too hard to get anything of interest done in standard non-scriptable XSLT, but worth paying the price of being locked into Microsoft's ecosystem.

I think it's better to forget about XSLT entirely, because it's a long lost cause, weak and ineffective at what it was designed, and use JavaScript and libraries like XPath to transform XML (and that goes squared for JSON), to reap the advantages of the latest JavaScript engines and libraries.

If Jolt is meant to be a language-independent standard, there should be a definitive reference implementation in JavaScript.

(in reply to arethuza's reply:)

Yes, I'd rather have all the great things you can do in domain specific languages like XSLT (like XPath, CSS, RegEx, etc) packaged up into nice libraries I can call from JavaScript, instead of being big complex hybrid frameworks that call my little snippets of JavaScript, like Microsoft's extended XSLT.

Och yes - I was definitely not recommending preserving XSLT (or indeed a JSON based equivalent). I always found that special purpose languages like XSLT were quite good but that for most tasks general purpose programming languages were far better so - the times that recursive pattern matched templates in XSLT made sense were few and far between.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact