1. 12
  1.  

  2. 10

    I honestly prefer SXML over either.

    1. 4

      Same, I’ve been bulding a website with haunt and am pleasantly surprised by how nice it is to write “html” using scheme.

    2. 7

      I agree with the author. I am always a little amazed , but it happens literally every time, I say the word “xml” someone is bound to reply “why not json!?!” I think it is weird because in my mind they are significantly different. Like the article says, xml does a good job at trees (though I think json does OK at this too), but it also is just excellent at adding meta data to existing strings. json is extremely awkward at doing that.

      Think about a html string. Like Hello, <span class="name">friend</span>, I am really <i>glad</i> to see you.

      Expressing that as json is possible, just super awkward. It’d look like a serialized tree of structs - which is probably what it would be in the source code so there’s sometimes value to that - but the xml fits fairly well.

      There’s other things I like about xml too…. and things I like about json. I just don’t see very much overlap between them.

      1. 5

        JSON vs XML is basically because some lovely people decided to use XML for their data, and JSON works a bit better at that. Sure, fine. Better tool for the job I guess.

        That does not mean a markup language (XML - hint at the name) will perform worse in markup than one that is not for markup. Hence, our age old issues.

        There is a reason we use HTML and not JSON for web pages.

        1. 2

          I don’t really buy the argument. That isn’t to say I disagree and think JSON (or some other representation) is better, but I don’t think the syntax matters all that much. I also don’t think the invented collection encodings or $type prefix notations are necessary in either case.

          I think the two encodings are roughly equivalent, and I can’t see a technical reason why one “beats” the other. You might prefer one over the other for some aesthetic reason, but that’s not the argument made in the article. If a colleague were to present this argument to me, I’d suggest they just write [de]serialisers for both encodings.

          1. 1

            XML when done right isn’t bad - it’s people who just use some sort of XML (like in the example with the attributes) and without a DTD to validate..

            And I suppose there’s JSON Schema but I’ve never seen anyone use it so far.

            1. 1

              I’ve found XML nicer also better to parse as you get SAX parsing which provides you another tool to keep memory usage and latencies predictable. Also with a little thought you can strap your chunked HTTP stream into your zlib decompressor and poke directly your internal data structure.

              Of course this really shines for large payloads.

          2. -1

            JSON vs XML are practically different syntaxes for the same thing and it probably doesn’t matter which you choose. It wouldn’t make or break your program, project, or business (except for the fact pretty much every API uses JSON). The example where JSON “loses” is contrived anyhow; it’s not really a good way to structure this kind of data in my opinion.

            1. 2

              This is not true.

              They have both been used for passing around data. However, one of them is actually a markup language. JSON is not for that, and is horrifyingly weird at it because of that.

              1. 2

                It is true in the sense that they can both serialize any known data (and both require you to figure out your own solutions for e.g. backreferences).

                Tooling matters, though. If you aren’t planning to build your own high-quality tooling, you are better off choosing a serialization format which already has it (where ‘quality’ is extremely contextual to both the team and problem space).

                1. 2

                  Yes.

                  However, my point is that XML is a markup language meaning that it is very good for annotating / marking up documents. Doing that with JSON is a horrifying experience. Hence, they are not “different syntaxes for the same thing”.

                  1. 1

                    Anything you can represent with one can be represented with the other.

                    Doing markup with JSON is a horrifying experience because the tooling sucks. You could (although it would be pointless) provide an editor that presented the user with XML and stored JSON.

                    That’s what I mean when I say they are different syntaxes for the same thing (as are all serialization formats). The serialization format is one of the least relevant details possible - what matters are:

                    • The data model, of which the format is one representation.
                    • The tooling, without which you’re stuck in the stone age, hand-editing files and hoping they work.

                    My current minimum standards for data tooling are:

                    • Automatic generation of parsing and serialization code (for any subset of your data)
                    • Ability to perform validity checking on a given serialization against a model (whether of the complete data model or a slice of it)

                    You can get this much with e.g. rails today.

                    1. 1

                      Yeah… no.

                      They are not serialization formats. XML for example is a markup language that you program / annotate / markup in. If you want to treat them as “it will be used by the programs only” be my guest, then I don’t care about your format. However, from a language design perspective JSON is not even comparable to XML.

                      Again, there is a reason our websites are in HTML and not JSON. There is a reason even in JS, with JSX, XML-like syntax comes back around and around.

                      1. 1

                        I am beginning to think I understand your point, but want to make sure:

                        You are talking about languages, but you don’t think languages are serialization formats. On this point I disagree wholeheartedly; even human languages are serialization formats, and computer ones particularly are.

                        From there, I suspect you are taking ‘as read’ that computer languages are written in a text editor with little-to-no comprehension of the language grammar (perhaps syntax editing, autoclosing tags etc but rarely eg autocomplete for css classes in html files). On this point I also disagree - IMO it’s a tremendous failure of imagination that we’ve stopped at ‘great text editor’.

                        1. 2

                          For the data serialization point; maybe I should have been a bit more clearer. Of course we can say that “any deterministic, structured encoding is a serialization format”. That would be first of all way too vague, especially for this discussion, since that is a great chunk of everything. Discussing the differences of XML and JSON requires us to focus on what makes them different there. Sorry for the confusion.

                          Secondly, while tooling can improve your quality of life a lot; that does not mean it is a part of the language’s own design. Having a language that has been made with the markup on mind is much more different compared to one that was made predominantly for data interchange especially in regards of objects.

                          And finally, if you have such a tooling that encompasses the whole language to the point that it should be considered a part of it - by all means be my guest. I don’t think a language has to be text based, (for example Blueprint from Unreal Engine should be seen as a programming language) however I believe that the ones we are talking about are predominantly text based. Should there be something that improves both on coding and reading in regards to this discussion, of course that would warrant a new perspective on it.

                          I hope I have been able to clarify it a bit more.

                          1. 2

                            Thanks, that makes sense :)

                2. 1

                  JSON vs XML are practically different syntaxes for the same thing

                  In the simplest use cases that may be true, but does everyone really want to reinvent the advanced stuff that some people need? If you need to provide any level of extensibility for JSON you are going to have to support your own system for namespacing, but XML has a standard version of this. It also has multiple methods of validation which interop with the extensibility. If you need a mechanism to convert one document into another then you have a standardised set of tools for transformation. Again, all these tools interoperate to a large degree.

                  None of these tools are easy, or perfect. They are far from it, created a long time ago (before JSON became popular), and have a lot of complexity (only some of it essential.) This makes the learning curve somewhat difficult, but there is no denying it is a powerful toolset for those that need it. Sometimes it may be worth inventing your own thing on top of JSON, or running with what you feel is a maintainable JSON toolset, but this decision isn’t as simple as you make it seem in all cases.