4 ms·

Dealing with it. Namespaces, attribute access, type-casting, the entire shebang. JSON can be very easily natively represented in just about any language: you h

Dealing with it. Namespaces, attribute access, type-casting, the entire shebang. JSON can be very easily natively represented in just about any language: you have objects/hashmaps/dicts, arrays, booleans, strings, numbers, and null. This means that accessing something in a JSON object is simple - you just use standard member access in your language of choice. XML is considerably harder to use - you have children, and attributes. You have namespaces, and so on. These make it impossible to use a basic 'data model' like for JSON - instead you need interactive objects, that let you traverse the tree. You can no longer simply map/filter/reduce over data. You can't easily access deeply nested structures without lots of syntax clutter. You can't easily serialize back and forth. Instead of using what your language already provides for data structures, you now need to learn an entirely new one, specifically for XML. That is what is 'difficult' in XML - it considerably increases the cognitive load for working with it. You can't keep the structure in your head easily, but need to look at documentation instead, and need to learn a specific (often bulky!) API just to interact with the data. Realistically, XML is useful for storage of complex data, but you really shouldn't be using it for wire serialization like XMPP does. XML is useful in a small subset of usecases, and trying to apply it to everything else is a mistake.

treffer 11y ago
Namespaces is something I consider a strong plus for XMPP. You may want to extend the data model at some point. You need a way to say "this is my extension, please ignore it". Or at least you need it if you want multiple implementations to work together. This makes it possible to experiment over the live xmpp network. map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)
- joepie91_ 11y ago
  > Namespaces is something I consider a strong plus for XMPP. You may want to extend the data model at some point. You need a way to say "this is my extension, please ignore it". Or at least you need it if you want multiple implementations to work together. Sure. The problem is that in every implementation I've seen, they're unreasonably hard to work with. Giving each extension its own key in a JSON object accomplishes the same, without breaking the native data model. > map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-) Yes, it's possible, but it's too hard. It always introduces more complexity when compared to standard deserialized JSON (in any language that can natively represent the JSON data types, which seems to be most).
  - TylerE 11y ago
    In fairness....in some statically typed languages like Go, working with JSON isn't a ton of fun either, if you need things like optional fields.
    - kuschku 11y ago
      Well, that’s not a limitation of statically typed languages, but a limitation of go. Just like Generics. Java, for example, does support Optional types similar to Haskell’s Maybe. Haskell in supports them, too
- acdha 11y ago
  Namespaces are a nice idea but almost all XML libraries make them unnecessarily cumbersome by requiring full specification everywhere. I sometimes wonder whether just fixing that would have made XML more popular after having seen so many people try to write something like a selector using the format in the document (ns:element), burning time until they learned that you have to use FULL_URL:element and in some cases even declare the namespace names you can't use. No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML.
  - joepie91_ 11y ago
    > No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML. This is the core issue with XML/XMPP. UX simply doesn't seem to have ever been a factor when designing either of them - whether towards the developers or the end users.
    - acdha 11y ago
      Agreed: the XML and Java communities from the late 90s were plagued by the assumption that complexity was intrinsically good and that everyone wants to spend the time required to completely internalize a massive specification and all of its dependencies.
      - dvanduzer 11y ago
        That is not at all a good characterization of what was going on. Do you remember what it was like before XML and Java? Could we have built anything on the scale of the web with CORBA? (XMPP would've used JSON had it existed in 1998, fwiw.)
        jessaustin 11y ago
        In what sense was the web built on "XML and Java"?
sz4kerto 11y ago
I don't know. Namespaces can be complex, yes -- if you use them. You are not obliged to. Also, XML schemas and XSLT are immensely useful (the lack of schemas is one of the most annoying issues with JSON).
- joepie91_ 11y ago
  JSON doesn't lack schemas: http://json-schema.org/ http://json-schema.org/ And yes, you absolutely do have to use namespaces when working with a third-party protocol that chooses to use them. You can't opt out.

treffer 11y ago

Namespaces is something I consider a strong plus for XMPP. You may want to extend the data model at some point. You need a way to say "this is my extension, please ignore it". Or at least you need it if you want multiple implementations to work together. This makes it possible to experiment over the live xmpp network. map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)

joepie91_ 11y ago
> Namespaces is something I consider a strong plus for XMPP. You may want to extend the data model at some point. You need a way to say "this is my extension, please ignore it". Or at least you need it if you want multiple implementations to work together. Sure. The problem is that in every implementation I've seen, they're unreasonably hard to work with. Giving each extension its own key in a JSON object accomplishes the same, without breaking the native data model. > map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-) Yes, it's possible, but it's too hard. It always introduces more complexity when compared to standard deserialized JSON (in any language that can natively represent the JSON data types, which seems to be most).
- TylerE 11y ago
  In fairness....in some statically typed languages like Go, working with JSON isn't a ton of fun either, if you need things like optional fields.
  - kuschku 11y ago
    Well, that’s not a limitation of statically typed languages, but a limitation of go. Just like Generics. Java, for example, does support Optional types similar to Haskell’s Maybe. Haskell in supports them, too
acdha 11y ago
Namespaces are a nice idea but almost all XML libraries make them unnecessarily cumbersome by requiring full specification everywhere. I sometimes wonder whether just fixing that would have made XML more popular after having seen so many people try to write something like a selector using the format in the document (ns:element), burning time until they learned that you have to use FULL_URL:element and in some cases even declare the namespace names you can't use. No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML.
- joepie91_ 11y ago
  > No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML. This is the core issue with XML/XMPP. UX simply doesn't seem to have ever been a factor when designing either of them - whether towards the developers or the end users.
  - acdha 11y ago
    Agreed: the XML and Java communities from the late 90s were plagued by the assumption that complexity was intrinsically good and that everyone wants to spend the time required to completely internalize a massive specification and all of its dependencies.
    - dvanduzer 11y ago
      That is not at all a good characterization of what was going on. Do you remember what it was like before XML and Java? Could we have built anything on the scale of the web with CORBA? (XMPP would've used JSON had it existed in 1998, fwiw.)
      - jessaustin 11y ago
        In what sense was the web built on "XML and Java"?

sz4kerto 11y ago

I don't know. Namespaces can be complex, yes -- if you use them. You are not obliged to. Also, XML schemas and XSLT are immensely useful (the lack of schemas is one of the most annoying issues with JSON).

joepie91_ 11y ago
JSON doesn't lack schemas: http://json-schema.org/ http://json-schema.org/ And yes, you absolutely do have to use namespaces when working with a third-party protocol that chooses to use them. You can't opt out.