5 ms·

It's easy enough to create an alternative syntax for it, one-to-one translation. For HTML (XHTML?) there are plenty examples already like Jade. http://jade-lan

by xaduha 11y ago

It's easy enough to create an alternative syntax for it, one-to-one translation. For HTML (XHTML?) there are plenty examples already like Jade. http://jade-lang.com/ http://jade-lang.com/ But people who are serious about XML-related technologies understand that syntax of XML is mostly fine, interoperability and existing tools matter way more. It would be hard for such an alternative syntax to catch on. People often forget that it is a direct descendant of SGML, I imagine for similar reasons - there were existing tools for it.

scotty79 11y ago
> syntax of XML is mostly fine If that was entirely true there'd be no JSON.
- xaduha 11y ago
  Are you even serious? Of course there would be different formats for every goddamn thing under the Sun. What really happens there is called Impedance Mismatch Similar to this, but with XML https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi... Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. There are different programming paradigms and I would (entirely serious here) say that XSLT, XQuery, XProc and related XML technologies belong to a separate category. It's mostly declarative and pure, but there are some imperative elements here and there. It's just a different way of doing things, which has XML and XPath at the very center. JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there.
  - scotty79 11y ago
    I'm serious. We had AJAX not AJAJ. JSON mostly replaced XML in its only popular application. There would be no point of having JSON (as a thing not just JS notation for object literals) if XML wasn't that horrible to look at. > Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. Funny how well having (sort-of) xml as first class citizen works in React ecosystem (in HTML too, to some degree). Easily composable bite sized chunks without over-engineered namespaces, doctypes and such. If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. > It's mostly declarative and pure, but there are some imperative elements here and there. Yes. And despite all that it gets almost no love. My point is that this is mainly because of syntax (a thing that is considered by many, superficial and unimportant). > JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there. I believe you are overthinking this. JSON is just xml subset with slightly different syntax. If there is no mismatch between JSON and Javascript on any level beyond the syntax then there was no mismatch between subset of XML that was used for same purpose before JSON became popular.
    - xaduha 11y ago
      With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. There are wrappers around DOM, like jQuery, but even that leads to some spaghetti code. JSON is a first class citizen in JS, XML isn't and never was. E4X never was properly supported by browsers. Namespaces and doctypes are not mandatory. Merits of a language and/or framework has little to do with it's popularity. There are much better languages/frameworks than Go or Angular, for example, but that doesn't make them popular. I'm not overthinking it, it's not my idea in the first place. > If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. That's just plain nonsense, what are you talking about? Nothing was stopping you from using XML the way it used in React. In fact these recent 'discoveries' in Javascript-land (React, Flux, Redux) are totally not new ideas.
      - scotty79 11y ago
        > With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.
TeMPOraL 11y ago
The reason it's "easy enough to create an alternative syntax for it, one-to-one translation" is because XML document is a tree. Just that. There's an argument to be had about tooling & specification ecosystem, but that can be replicated in other formats, and if all you want is hierarchical data representation, it's not worth it to poke your eyes out while working with human-unreadable format XML is.
- xaduha 11y ago
  What's important about XML isn't XML itself. It's specifications, standards, toolset. Just because it can be replicated doesn't it will be. That's probably man-centuries of work.
  - TeMPOraL 11y ago
    I agree. Though a big part of the XML ecosystem is made of dead ends and very domain-specific stuff. But either way, we need to be precise - let's evaluate XML and XML ecosystem separately. If you're not heavily exploiting the latter, XML is almost never a good choice - because alone by itself, it's just a tree notation that sucks.
deleted 11y ago
[deleted]

by xaduha 11y ago

scotty79 11y ago

> syntax of XML is mostly fine If that was entirely true there'd be no JSON.

xaduha 11y ago
Are you even serious? Of course there would be different formats for every goddamn thing under the Sun. What really happens there is called Impedance Mismatch Similar to this, but with XML https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi... Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. There are different programming paradigms and I would (entirely serious here) say that XSLT, XQuery, XProc and related XML technologies belong to a separate category. It's mostly declarative and pure, but there are some imperative elements here and there. It's just a different way of doing things, which has XML and XPath at the very center. JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there.
- scotty79 11y ago
  I'm serious. We had AJAX not AJAJ. JSON mostly replaced XML in its only popular application. There would be no point of having JSON (as a thing not just JS notation for object literals) if XML wasn't that horrible to look at. > Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. Funny how well having (sort-of) xml as first class citizen works in React ecosystem (in HTML too, to some degree). Easily composable bite sized chunks without over-engineered namespaces, doctypes and such. If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. > It's mostly declarative and pure, but there are some imperative elements here and there. Yes. And despite all that it gets almost no love. My point is that this is mainly because of syntax (a thing that is considered by many, superficial and unimportant). > JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there. I believe you are overthinking this. JSON is just xml subset with slightly different syntax. If there is no mismatch between JSON and Javascript on any level beyond the syntax then there was no mismatch between subset of XML that was used for same purpose before JSON became popular.
  - xaduha 11y ago
    With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. There are wrappers around DOM, like jQuery, but even that leads to some spaghetti code. JSON is a first class citizen in JS, XML isn't and never was. E4X never was properly supported by browsers. Namespaces and doctypes are not mandatory. Merits of a language and/or framework has little to do with it's popularity. There are much better languages/frameworks than Go or Angular, for example, but that doesn't make them popular. I'm not overthinking it, it's not my idea in the first place. > If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. That's just plain nonsense, what are you talking about? Nothing was stopping you from using XML the way it used in React. In fact these recent 'discoveries' in Javascript-land (React, Flux, Redux) are totally not new ideas.
    - scotty79 11y ago
      > With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.

TeMPOraL 11y ago

The reason it's "easy enough to create an alternative syntax for it, one-to-one translation" is because XML document is a tree. Just that. There's an argument to be had about tooling & specification ecosystem, but that can be replicated in other formats, and if all you want is hierarchical data representation, it's not worth it to poke your eyes out while working with human-unreadable format XML is.

xaduha 11y ago
What's important about XML isn't XML itself. It's specifications, standards, toolset. Just because it can be replicated doesn't it will be. That's probably man-centuries of work.
- TeMPOraL 11y ago
  I agree. Though a big part of the XML ecosystem is made of dead ends and very domain-specific stuff. But either way, we need to be precise - let's evaluate XML and XML ecosystem separately. If you're not heavily exploiting the latter, XML is almost never a good choice - because alone by itself, it's just a tree notation that sucks.

deleted 11y ago

[deleted]