11 ms·

Alternate title: "XML performs as badly as JSON". JSON is used because Javascript, Python and Ruby (among others) understand it without needed external librari

by Wilya 13y ago

Alternate title: "XML performs as badly as JSON". JSON is used because Javascript, Python and Ruby (among others) understand it without needed external libraries, and because it's fairly readable for humans. Performance has nothing to do with it. If you want performance and have some control on your stack, you're better off with something more specialized.

_ZeD_ 13y ago
JSON is used because Javascript, Python and Ruby (among others) understand it without needed external libraries I don't think neither this is the point: afaik browsers (where the most of the js is evaluated), python and ruby also have xml parsers in the "standard" lib (maybe more than one). What really matters is that javascript, python and ruby programmers undersand JSON without crying for the "<" and ">" presents in the xmls
- wisty 13y ago
  No, it's that standard XML libraries are over-engineered for the purposes they are used. First, you have to pick between SAX and DOM. If you pick SAX for a typical web-app, you've screwed up. Even if you pick DOM, there's a big impedance mismatch XML's data, and lists or hashes that programming languages use.
  - sixbrx 13y ago
    I agree there's an annoying mismatch between how XML treats data and almost any programming language does. Without an XML-Schema saying otherwise (and, yuck), XML supports arbitrarily interleaved sequences of mixed elements, which can't be mapped cleanly to data structures in common programming languages without extra meta-data being supplied somehow. Consider for example trying to map: <some-data> <a>...</a> <a>...</a> <b>...</b> <a>...</a> </some-data> You can automatically map the first sequence of a's to a "aList" collection in your programming language, but then what is the automatic mapping of the one or more a's that follow the b element? Should it be a list or a single item ? Or is it semantics preserving to just combine it with the previous collection? If it should be mapped to a collection, what would that collection's name be in the target language, so that it doesn't clash with the previous collection's name? Etc. Formats like Json avoid this problem by only supporting sequences as explicitly named collections, like most programming languages do within objects or structures. IOW with XML you can't really do a proper mapping without an accompanying schema or other metadata, which is not true for the Json data.
    - frobozz 13y ago
      This doesn't even look remotely unlike the behaviour of "almost any programming language". If you have an a set of people, do you separate them out into a "manList" and a "womanList", and then panic about having to create a "secondManList" because some men came in after the women? If order is only important within gender, then you can happily just add the men onto the end of the original manList. If it is important across all people, then you have to have a "personList". Just like you might have a "personList" that can contain "male people" and "female people", you can automatically map the whole sequence of "a elements" and "b elements" to an "elementList". In the case of mixed content (text nodes and element nodes together), you would simply map them all to a "nodeList".
      - sixbrx 13y ago
        I think you're making my point, with your inclusions of "if"'s ("If order is only important within gender") that a machine would not and generally cannot know, without understanding the semantics of the data to begin with. That's a disadvantage because that's precisely the sort of "extra metadata" that is needed to complete the XML mapping in the general case that I was talking about - it requires human intervention and therefore a custom one-off mapping, or else at least something like an XML schema [edit: more like JAXB annotations]. The Json doesn't require either of these. Also, do you really expect an automated process to do the abstraction from "female" list and "male" list to person list? That's more than just metadata that you're assuming to be in context (which was my point), but actual AI! This is very different from programming languages, where collections of things which occur within objects and structs are given names which reflect their intended meanings, like with Json.
        frobozz 13y ago
        But it's still no different to any other language. An XML element has two collection members, one representing the attributes, and another representing the child nodes. How is this different from a Java object which contains two list members called "attributes" and "children"? How is this different from an S-Expression containing two lists? How is this different from a json object like {"attributes":[...], "children":[...]}? Bear in mind that there is no requirement for JSON lists to be homgeneous. {"things":[1,true,"hello",3,{"addressee":"world"},[{"greeting":"Hola"},7],false]} is a perfectly valid JSON object. You don't have to define it as {"numbers":[1,3], "strings":["hello"] ...}. It is a pretty common behaviour, that if you want a homogeneous list of things that differ, then you make abstractions until the differences disappear, e.g in an OO situation, you go up the inheritance tree until you are at the lowest common base class. In an XML situation, that common base class is "Node". Even in a strongly typed language that requires homogeneity in lists, the only thing you know about the list members is that they can be cast to the same type, not that the members are of that type and no other, and certainly not that they all have the same name. Consider a C++ array of CFruit objects. It may have a member that is of class CBanana, one that of class CApple, and another of class COrange. If you want to do something COrange specific with the oranges, then you have to perform dynamic_cast<COrange> on any member of that list you suspect of being an orange. The same is true in a duck-typing situation. The reason for my male & female example is that you would normally simply have a list of people. Of course, if your model contains no base that is common to both men and women, then you can't expect the machine to work that out, but if Man and Woman both inherit from Person, or if there is no Man or Woman, just Person with a member that specifies a gender, then it's trivial.
  - jerf 13y ago
    "If you pick SAX for a typical web-app, you've screwed up." Way too glib. There's lots of good reasons you may choose to go with that, and there's lots of reasons why you may not. DOM-based approaches pay a lot of resources for their functionality. If you don't use all of that functionality, you may lose over a SAX-based approach. If you're resource rich, hey, great, go with DOM unconditionally, but not all web apps are in that situation. It's one advantage the XML ecosystem has over the JSON ecosystem; while JSON can be parsed in a streaming manner, you can generally count on a good XML event-based library for your environment, whereas streaming JSON parsing libraries seem more unusual. If you need it, you can count on it in XML.
    - wisty 13y ago
      Generally, SAX is only there because you have massive documents to process, or very constrained resources. Of course, you're right to say SAX has a place, and I did really oversimplify things. If you're using Ruby or Django though, and not processing large documents, I doubt switching to SAX would be a low-hanging fruit.
gioele 13y ago
Python and Ruby needed external libraries to understand JSON until those libraries have been moved into the respective standard libraries.
- kbenson 13y ago
  They needed external libraries to parse it, but the information is easily represented in native data structures, is it not? That's what people are referring to.
- droithomme 13y ago
  Do you use Python or Ruby? JSON has been in Python's standard library since 2008. http://docs.python.org/2/library/json.html http://docs.python.org/2/library/json.html It's also in the Ruby standard library. http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.html http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.h...
  - gioele 13y ago
    Your comment just reinforces my point: neither Python or Ruby supported JSON since their inception. JSON has been launched around 2002. Python has incorporated one of the many existing libraries in 2008 after a lengthy discussion, the last part of which is http://mail.python.org/pipermail/python-3000/2008-March/012583.html http://mail.python.org/pipermail/python-3000/2008-March/0125... Ruby had no support JSON for years, it has been added, in its current form, to the stdlib only in 2007. XML has been supported by Python since 2000 (minidom + sax) and by Ruby since 2003 (REXML). The idea that JSON is used more than XML just because programming language supports it "natively" clashes with the evidence.
juandopazo 13y ago
I don't think it's about built-in support. I believe it's about how JSON maps to common language constructs such as lists and hash tables. XML on the other hand needs to map to a complex tree structure that requires another level of abstraction.

by Wilya 13y ago

_ZeD_ 13y ago

JSON is used because Javascript, Python and Ruby (among others) understand it without needed external libraries I don't think neither this is the point: afaik browsers (where the most of the js is evaluated), python and ruby also have xml parsers in the "standard" lib (maybe more than one). What really matters is that javascript, python and ruby programmers undersand JSON without crying for the "<" and ">" presents in the xmls

wisty 13y ago
No, it's that standard XML libraries are over-engineered for the purposes they are used. First, you have to pick between SAX and DOM. If you pick SAX for a typical web-app, you've screwed up. Even if you pick DOM, there's a big impedance mismatch XML's data, and lists or hashes that programming languages use.
- sixbrx 13y ago
  I agree there's an annoying mismatch between how XML treats data and almost any programming language does. Without an XML-Schema saying otherwise (and, yuck), XML supports arbitrarily interleaved sequences of mixed elements, which can't be mapped cleanly to data structures in common programming languages without extra meta-data being supplied somehow. Consider for example trying to map: <some-data> <a>...</a> <a>...</a> <b>...</b> <a>...</a> </some-data> You can automatically map the first sequence of a's to a "aList" collection in your programming language, but then what is the automatic mapping of the one or more a's that follow the b element? Should it be a list or a single item ? Or is it semantics preserving to just combine it with the previous collection? If it should be mapped to a collection, what would that collection's name be in the target language, so that it doesn't clash with the previous collection's name? Etc. Formats like Json avoid this problem by only supporting sequences as explicitly named collections, like most programming languages do within objects or structures. IOW with XML you can't really do a proper mapping without an accompanying schema or other metadata, which is not true for the Json data.
  - frobozz 13y ago
    This doesn't even look remotely unlike the behaviour of "almost any programming language". If you have an a set of people, do you separate them out into a "manList" and a "womanList", and then panic about having to create a "secondManList" because some men came in after the women? If order is only important within gender, then you can happily just add the men onto the end of the original manList. If it is important across all people, then you have to have a "personList". Just like you might have a "personList" that can contain "male people" and "female people", you can automatically map the whole sequence of "a elements" and "b elements" to an "elementList". In the case of mixed content (text nodes and element nodes together), you would simply map them all to a "nodeList".
    - sixbrx 13y ago
      I think you're making my point, with your inclusions of "if"'s ("If order is only important within gender") that a machine would not and generally cannot know, without understanding the semantics of the data to begin with. That's a disadvantage because that's precisely the sort of "extra metadata" that is needed to complete the XML mapping in the general case that I was talking about - it requires human intervention and therefore a custom one-off mapping, or else at least something like an XML schema [edit: more like JAXB annotations]. The Json doesn't require either of these. Also, do you really expect an automated process to do the abstraction from "female" list and "male" list to person list? That's more than just metadata that you're assuming to be in context (which was my point), but actual AI! This is very different from programming languages, where collections of things which occur within objects and structs are given names which reflect their intended meanings, like with Json.
      - frobozz 13y ago
        But it's still no different to any other language. An XML element has two collection members, one representing the attributes, and another representing the child nodes. How is this different from a Java object which contains two list members called "attributes" and "children"? How is this different from an S-Expression containing two lists? How is this different from a json object like {"attributes":[...], "children":[...]}? Bear in mind that there is no requirement for JSON lists to be homgeneous. {"things":[1,true,"hello",3,{"addressee":"world"},[{"greeting":"Hola"},7],false]} is a perfectly valid JSON object. You don't have to define it as {"numbers":[1,3], "strings":["hello"] ...}. It is a pretty common behaviour, that if you want a homogeneous list of things that differ, then you make abstractions until the differences disappear, e.g in an OO situation, you go up the inheritance tree until you are at the lowest common base class. In an XML situation, that common base class is "Node". Even in a strongly typed language that requires homogeneity in lists, the only thing you know about the list members is that they can be cast to the same type, not that the members are of that type and no other, and certainly not that they all have the same name. Consider a C++ array of CFruit objects. It may have a member that is of class CBanana, one that of class CApple, and another of class COrange. If you want to do something COrange specific with the oranges, then you have to perform dynamic_cast<COrange> on any member of that list you suspect of being an orange. The same is true in a duck-typing situation. The reason for my male & female example is that you would normally simply have a list of people. Of course, if your model contains no base that is common to both men and women, then you can't expect the machine to work that out, but if Man and Woman both inherit from Person, or if there is no Man or Woman, just Person with a member that specifies a gender, then it's trivial.
- jerf 13y ago
  "If you pick SAX for a typical web-app, you've screwed up." Way too glib. There's lots of good reasons you may choose to go with that, and there's lots of reasons why you may not. DOM-based approaches pay a lot of resources for their functionality. If you don't use all of that functionality, you may lose over a SAX-based approach. If you're resource rich, hey, great, go with DOM unconditionally, but not all web apps are in that situation. It's one advantage the XML ecosystem has over the JSON ecosystem; while JSON can be parsed in a streaming manner, you can generally count on a good XML event-based library for your environment, whereas streaming JSON parsing libraries seem more unusual. If you need it, you can count on it in XML.
  - wisty 13y ago
    Generally, SAX is only there because you have massive documents to process, or very constrained resources. Of course, you're right to say SAX has a place, and I did really oversimplify things. If you're using Ruby or Django though, and not processing large documents, I doubt switching to SAX would be a low-hanging fruit.

gioele 13y ago

Python and Ruby needed external libraries to understand JSON until those libraries have been moved into the respective standard libraries.

kbenson 13y ago
They needed external libraries to parse it, but the information is easily represented in native data structures, is it not? That's what people are referring to.
droithomme 13y ago
Do you use Python or Ruby? JSON has been in Python's standard library since 2008. http://docs.python.org/2/library/json.html http://docs.python.org/2/library/json.html It's also in the Ruby standard library. http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.html http://www.ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON.h...
- gioele 13y ago
  Your comment just reinforces my point: neither Python or Ruby supported JSON since their inception. JSON has been launched around 2002. Python has incorporated one of the many existing libraries in 2008 after a lengthy discussion, the last part of which is http://mail.python.org/pipermail/python-3000/2008-March/012583.html http://mail.python.org/pipermail/python-3000/2008-March/0125... Ruby had no support JSON for years, it has been added, in its current form, to the stdlib only in 2007. XML has been supported by Python since 2000 (minidom + sax) and by Ruby since 2003 (REXML). The idea that JSON is used more than XML just because programming language supports it "natively" clashes with the evidence.

juandopazo 13y ago

I don't think it's about built-in support. I believe it's about how JSON maps to common language constructs such as lists and hash tables. XML on the other hand needs to map to a complex tree structure that requires another level of abstraction.