4 ms·

If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world

If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. Even though YAML is not optimal, it is a human friendly compromise between too verbose XML and machine only JSON. It lacks native templating, leading to funny constructs e.g. with Ansible files. However human kind has made progress and will make progress further, so it is just a matter of time until someone comes up with sane "native templated YAML" and all projects will adopt it.

chriswarbo 8y ago
> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. I actually really like the idea behind XSLT: machine-friendly, human-tolerable, structured data + declarative rules for turning that data into a display, or a report, or whatever else. The execution was horrible though: incredibly verbose, lots of overcomplication due to XML weirdness/asymmetries (e.g. attributes vs elements vs text, namespaces, ...); mixtures of different languages hidden inside each other (e.g. XPath hidden in attributes); etc. I would really like to see what this could look like if done in a more minimalist, lispy fashion (normal code-is-data stuff in Lisp is similar, but I think term-rewriting is a more appropriate evaluation mechanism for such rules)
- pytester 8y ago
  XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.
  - astine 8y ago
    I don't see a reason that a DSL can't be Turing complete and still a better option than an existing language. If you look at old-school make files, they are little more than shell script with top level rules that you can invoke from the command line. You could theoretically just use shell script but the make scripts still simplify the task quite a bit.
  - thanatropism 8y ago
    There was a post on HN a few weeks back to the effect that it's rather easy for Turing completeness to emerge accidentally. I wish I remembered more specifics so I could find it again.
    - chriswarbo 8y ago
      Was it http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... by any chance?
  - hyperpallium 8y ago
    Less power means less to go wrong. Automatic checks can also be deeper in a simpler system. Your point is valid though, the power seems to end up being needed, sometimes, in some parts, in some cases. Escaping to a full language when needed seems to retain the benefits of both worlds.
  - miohtama 8y ago
    I wrote a lot of XMLT in early 2000. The idea behind pure function is nice, but in practice you ended up with hundreds of mini plugins in Java or Python.
- hyperpallium 8y ago
  The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... jq occupies the same role as XSLT, but for JSON. It can be used for templating but it's not quite as declarative as XSLT (you must pipe things through).
  - int_19h 8y ago
    XQuery was halfway between XSLT and XPath in expressiveness - functions, loops, queries with joins etc, but no pattern matching. If it only had the latter, it'd be perfect.
  - chriswarbo 8y ago
    > The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... Yes, I didn't mean to imply that XPath itself is bad (although it also has to handle XML quirks like element/attribute/text, etc.). Rather that the reason to write XSLT as XML in the first place is that it's machine readable, we can mix and match elements from different vocabularies, etc. yet most of the heavy lifting ends up as opaque string attributes :( PS: I've done a few projects which make heavy use of jq; it's really nice, but as you say it's more of a pipeline.
  - mst 8y ago
    I quite liked SXML + SXSLT back in the day (scheme syntax)
    - hyperpallium 8y ago
      It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm... (parrot (@ (type "African Grey")) (name "Alfie")) <parrot> <type>African Grey</type> <name>Alfie</name> </parrot> It's more the one-variable-per-line pretty-printing than the syntax as such, but still.
- james_s_tayler 8y ago
  I find XSLT intolerable in practice. Thankfully I've only had to touch it a handful of times. I agree the idea behind it is neat but boy is it a headache.
NicoJuicy 8y ago
I actually like XML templating, it's the only one that supports it in the file. I export custom queries for data to xml, Json, CSV and HTML. Where HTML is XML + XSLT. It works great. And clients can even theme it
- pjmlp 8y ago
  I also like it, for a couple of years my web site was XML + XSLT.
dagss 8y ago
What you say you want is XSLT though, just wity a better syntax and for YAML. XSLT was just fine, had a lot of very good ideas, just horrible syntax. Horrible syntax is kind of a forgivable offense, lots of things have horrible syntax and work fine. Generating YAML with go templates though.. it is just horrible on so many levels. I definitely feel the 90s can take the higher ground over 2010s on this one.
int_19h 8y ago
I kinda miss it, actually. XML had many warts, but at least everybody spoke it, and it was the same everywhere. Occasionally you still had some overlapping but different things, like XSD and RELAX NG schemas (though even there, there was a big difference - one is a language for describing data types, and the other is a language for describing grammars). But it's better than several dialects of JSON, YAML, TOML etc. I also rather liked thorough extensibility. Namespaces were the right idea, despite clunky syntax. Today you can see Clojure doing something similar in Spec. And while we're on the subject of XML, XSLT and Clojure; I feel like this is the best solution for readable serialization of tree-like data, and an associated ecosystem of tools (to validate, transform etc). Note some nice features for humans, like the ability to comment out a specific node, in addition to the usual line-oriented comments. https://github.com/edn-format/edn https://github.com/edn-format/edn
- miohtama 8y ago
  As, I think Douglas Crockford said, the best thing that XML delivered was UTF-8. Then we have built a whole new domain on things on the top of UTF-8.

chriswarbo 8y ago

> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. I actually really like the idea behind XSLT: machine-friendly, human-tolerable, structured data + declarative rules for turning that data into a display, or a report, or whatever else. The execution was horrible though: incredibly verbose, lots of overcomplication due to XML weirdness/asymmetries (e.g. attributes vs elements vs text, namespaces, ...); mixtures of different languages hidden inside each other (e.g. XPath hidden in attributes); etc. I would really like to see what this could look like if done in a more minimalist, lispy fashion (normal code-is-data stuff in Lisp is similar, but I think term-rewriting is a more appropriate evaluation mechanism for such rules)

pytester 8y ago
XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.
- astine 8y ago
  I don't see a reason that a DSL can't be Turing complete and still a better option than an existing language. If you look at old-school make files, they are little more than shell script with top level rules that you can invoke from the command line. You could theoretically just use shell script but the make scripts still simplify the task quite a bit.
- thanatropism 8y ago
  There was a post on HN a few weeks back to the effect that it's rather easy for Turing completeness to emerge accidentally. I wish I remembered more specifics so I could find it again.
  - chriswarbo 8y ago
    Was it http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... by any chance?
- hyperpallium 8y ago
  Less power means less to go wrong. Automatic checks can also be deeper in a simpler system. Your point is valid though, the power seems to end up being needed, sometimes, in some parts, in some cases. Escaping to a full language when needed seems to retain the benefits of both worlds.
- miohtama 8y ago
  I wrote a lot of XMLT in early 2000. The idea behind pure function is nice, but in practice you ended up with hundreds of mini plugins in Java or Python.
hyperpallium 8y ago
The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... jq occupies the same role as XSLT, but for JSON. It can be used for templating but it's not quite as declarative as XSLT (you must pipe things through).
- int_19h 8y ago
  XQuery was halfway between XSLT and XPath in expressiveness - functions, loops, queries with joins etc, but no pattern matching. If it only had the latter, it'd be perfect.
- chriswarbo 8y ago
  > The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... Yes, I didn't mean to imply that XPath itself is bad (although it also has to handle XML quirks like element/attribute/text, etc.). Rather that the reason to write XSLT as XML in the first place is that it's machine readable, we can mix and match elements from different vocabularies, etc. yet most of the heavy lifting ends up as opaque string attributes :( PS: I've done a few projects which make heavy use of jq; it's really nice, but as you say it's more of a pipeline.
- mst 8y ago
  I quite liked SXML + SXSLT back in the day (scheme syntax)
  - hyperpallium 8y ago
    It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm... (parrot (@ (type "African Grey")) (name "Alfie")) <parrot> <type>African Grey</type> <name>Alfie</name> </parrot> It's more the one-variable-per-line pretty-printing than the syntax as such, but still.
james_s_tayler 8y ago
I find XSLT intolerable in practice. Thankfully I've only had to touch it a handful of times. I agree the idea behind it is neat but boy is it a headache.

NicoJuicy 8y ago

I actually like XML templating, it's the only one that supports it in the file. I export custom queries for data to xml, Json, CSV and HTML. Where HTML is XML + XSLT. It works great. And clients can even theme it

pjmlp 8y ago
I also like it, for a couple of years my web site was XML + XSLT.

dagss 8y ago

What you say you want is XSLT though, just wity a better syntax and for YAML. XSLT was just fine, had a lot of very good ideas, just horrible syntax. Horrible syntax is kind of a forgivable offense, lots of things have horrible syntax and work fine. Generating YAML with go templates though.. it is just horrible on so many levels. I definitely feel the 90s can take the higher ground over 2010s on this one.

int_19h 8y ago

I kinda miss it, actually. XML had many warts, but at least everybody spoke it, and it was the same everywhere. Occasionally you still had some overlapping but different things, like XSD and RELAX NG schemas (though even there, there was a big difference - one is a language for describing data types, and the other is a language for describing grammars). But it's better than several dialects of JSON, YAML, TOML etc. I also rather liked thorough extensibility. Namespaces were the right idea, despite clunky syntax. Today you can see Clojure doing something similar in Spec. And while we're on the subject of XML, XSLT and Clojure; I feel like this is the best solution for readable serialization of tree-like data, and an associated ecosystem of tools (to validate, transform etc). Note some nice features for humans, like the ability to comment out a specific node, in addition to the usual line-oriented comments. https://github.com/edn-format/edn https://github.com/edn-format/edn

miohtama 8y ago
As, I think Douglas Crockford said, the best thing that XML delivered was UTF-8. Then we have built a whole new domain on things on the top of UTF-8.