7 ms·

I'm surprised to see XML. Wouldn't JSON or some other format be a better choice?

• Sir_Cmpwn 9y ago
  Why?
  • br1n0 9y ago
    Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js), and a serialization/deseriazation is unique, in xml you could put some infos on the attributes oand other on tags or as parameters. instead of <event name="gamma_size"> <arg name="size" type="uint"/> </event> {"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }
    • Sir_Cmpwn 9y ago
      >Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js) Wayland is not the web. None of these technologies are involved in Wayland. >{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" } Your example is more verbose and harder to read... XML is definitely misused in many applications where JSON is appropriate but this is not one of them.
      • pcwalton 9y ago
        JSON has problems, but that's why we have TOML: [gamma_size] type = "event" args = [ { name = "size", type = "uint" } ] XML isn't what I would choose here because there's no need for text markup. TOML is both simpler and friendlier than XML in this case. I do agree that it doesn't matter much.
        • Sir_Cmpwn 9y ago
          Wayland predates TOML, and I think TOML would be worse than XML for this use case.
          • pcwalton 9y ago
            I'd be happy to know your reasons why. Overall, XML is too verbose; in particular, the text markup features of XML are needless complexity.
            • Sir_Cmpwn 9y ago
              It's not. It's barely more verbose than JSON and a hell of a lot more readable. JSON is appropriate for machines to talk with. XML is appropriate for writing documentation or API specs.
              • sanbor 9y ago
                Thanks for the insight. Some of the comments revealed why xml was picked. I personally agree that depending on the problem you must pick the right tools and what might be a good suit in a context it might not be the best fit in another. Moreover, there are probably more mature and performant parsing libs in c for xml than for json. However, XML might be overkill as it might be too complex for this particular scenario. XML parsing it's complicated and from time to time there are bugs in those parsers. A simpler format might also get the job done and might be safer. However XML might provide flexibility to scale. Finally, this is what Torvalds said about XML when someone suggested to use it in git: > XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.
        • escape_goat 9y ago
          We have TOML in the sense that TOML is currently v0.4.0 and bears an explicit warning that the specification is unstable should be treated accordingly.
          • pcwalton 9y ago
            That's unfortunate, but there are a lot of projects out there that depend on TOML, and it hasn't changed since 2015. It's de facto stable at this point. The author has said as much: https://github.com/toml-lang/toml/issues/330 https://github.com/toml-lang/toml/issues/330
        • SmellyGeekBoy 9y ago
          Relevant xkcd: https://xkcd.com/927 https://xkcd.com/927
          • qb45 9y ago
            It's USB-C ;)
• ori_b 9y ago
  It doesn't matter; it's just a machine readable protocol description.
• quotemstr 9y ago
  XML has several advantages over JSON: it's much better at self-documentation and the schema validation tools are more powerful. Namespaces compose elegantly. XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.
  • jancsika 9y ago
    Do you or Sir_Cmpwn have a small, real-world example of elegant XML namespace composition in the context of Wayland? I didn't see XML namespaces used in the example given in the article, so I'm curious how Wayland leverages them.
  • legulere 9y ago
    I never saw a nice use-case of namespaces. Maybe you can show me one? So far I have only seen namespaces used by Inkscape to state that a SVG is a still image using 3 different name-spaces in one hierarchy. Does it not just add complexity to need to support different standards at the same time
    • barrkel 9y ago
      If you ever have to annotate one tree using a completely separate tool, you need to do something to ensure the names you choose are different from the ones used by whatever produces the tree. You can choose odd names, but there's no guarantee. Namespaces can provide that guarantee, via uniqueness of URIs, ultimately relying ICANN.
    • btschaegg 9y ago
      Almost certain this doesn't qualify as "nice", but: Namespaces make XSLT more powerful than one might think at first, because they allow you to write XSLT that generates XSLT (and so on...) by switching a namespace to a different one upon output generation. Of course, the result is often barely readable anymore, so there's that. Edit: On the other hand, the difference between XSLT-namespaced elements and all the others in a stylesheet is the one thing that makes basic XSLT readable, since you don't have to use a full meta-language just to create simple elements.