1. 8

  2. 25

    Start: JSON and XML are not comparable! Would you compare a bicycle and an AMG S65?

    Middle: Here are 4 ways in which XML is better than JSON.

    End: By the way, you can do this stuff in JSON too, but they are weak parodies, they have no future, I wish they would disappear, they’re clumsy (no argument given for any of this, just assertion).

    OK, so I guess they’re comparable after all. Would have been nice if a comparison would have actually been made, instead of a bunch of unsupported assertions.

    1. 8

      XML is not a data format; it is a language.

      Right. So what’s the difference?

      Also FWIW I’ve used XPath and XSL, and I’ve used jq, and jq is the one that strikes me as good enough to emulate.

      1. 3

        XML is a language in the sense that you can create XML applications using an XML schema and XSLT stylesheets. It it a language to describe structured data, its querying and transformation. A well-known application is the DocBook format. The killer feature of pure XML is namespaces and the interweaving of different XML applications in the same document, it is really a conceptual breakthrough.

        1. 3

          I’ve thought a bunch about the difference. :)

          XSLT is an imperative language (though it’s trying not to be, and its backbone is declarative - see my other comment for more). It is built on XML.

          C is an imperative language. It is built on text files. (The C89 standard had to define the structure of text files - specifically the use of line-feeds to terminate visual lines of text - because there wasn’t anything else to reference for it, at that time.)

          XML does have more structure than text files do, and there’s a case to be made that it’s a language. What it has - if we don’t consider other technologies layered on top of it - is mostly grammar rather than vocabulary. Tags, attributes, entities, … The vocabulary it does have is mostly around doctypes and namespaces, and that’s real, but it isn’t useful for anything. You could certainly define some sort of horrible Peano arithmetic in terms of doctype definitions, but nobody has, and please don’t. :)

          I don’t see a need to draw a final conclusion “XML is not a language”, but at least, if it’s a language, it’s not one that people have a need for except in combination with other languages. Does that feel like a satisfying answer to you?

          1. 2

            That’s reasonable. I take issue with the author’s implication that “… and JSON’s not.” They’re either both languages or neither languages. “Both” is I think the stronger position.

            1. 1


        2. 5

          XSLT is sadly not well know these days, but is such a powerful idea, and found relevance again with the advent of functional-style renderers like React. If XSLT had had the same love as other web technologies, we should be able to describe our app data as XML and style it dynamically using XSLT. A change in the original XML would then be translated directly using a fast XSLT transform into a DOM change. Alas, XSLT on browser is not meant to be used for interactive rendering.

          1. 5

            Having used XSLT in the past I have no sorrow at it falling into disuse. While the concept is good it’s horribly awkward to work with in practice.

            1. 4

              I love the idea of XSLT, in the abstract. Concretely, however, it has two serious problems, either of which would be enough for me to write it off.

              First, the syntax is itself XML; there are a concise DSLs within it for a few specialized tasks, which aren’t too bad, but you wind up writing out flow control as balanced XML tags, and it’s horrifyingly verbose. It’s like somebody didn’t get the memo that yes, people weren’t just criticizing the verbosity of XML to be edgy, it’s a real weakness which makes it not suitable for use as a general-purpose programming language.

              Second, the concepts of it are pretty but turn out not to be a good fit for the problem domain. They’re kind of idealistically trying to be pure-functional descriptions of transformations, but in reality they have a lot of side effects, and with anything complicated you also have to keep track of subtle rules about what order transformations happen in. At that point, it should just be an imperative language, because the ordering is so crucial to making it work. There may be some other way to model these transformations that really is pure-functional, but at least XSLT’s attempt failed to do it.

              And as people have said, those transformations also turn out not to be a good fit for how browsers work.

              If anyone wants to look at this for themselves, we recommend the Docbook stylesheets as an example. They may be the largest XSLT codebase. Try adding a small feature to them and you’ll get the idea. :)

              1. 3

                Sadly, we must instead describe data as xml and style it with CSS

                1. 4

                  I think what Sebastien’s saying is if the styling was an XML -> XML transformation, you could have your semantic document and a pass to make it into something displayable, but the output would still be structured as an XML document. Whereas with CSS, applying a stylesheet just results in some internal DOM structure that’s less amenable to further transformation. It’s not a bad idea. Though practically speaking, XSLT is a pain to use so one would hope for a better transform language.

                  1. 2

                    Applying a CSS stylesheet to your XML data doesn’t result in a new XML document - just different pixels on the screen.

                    These days you can position anything anywhere, even order in the document doesn’t have to matter.

                    1. 2

                      That’s what I mean. CSS doesn’t, but you could have a stylesheet pass that does result in “tangible” XML documents, assumedly with styling tacked on as attributes. Then you could compose these or apply them server-side. Also the result would be you’re using a general transformer rather than yet another special-purpose tool, which would be nice.

                2. 3

                  Sexps are sadly not well known these days…

                3. 4

                  The trouble with XML is there is one and only one tool that it really fits and is good at manipulating it… XSLT.

                  For every other language out there, trying to fit the XML data model into the languages primitives is like trying to stuff an octopus into a starfish shaped hole.

                  XPath/XQuery always feels to me like a pile of insane cunning and work applied towards a wrong goal.

                  It’s as if someone read CJ Date’s complete well reasoned recommendations…. and decided maximally violate every single one of them.

                  1. 0

                    XML is a lot used as a serialization format and it is a terrible one.